[Sync] Add favicon datatype proto support

sync/protocol/favicon_tracking_specifics.proto

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+//
+// Sync protocol datatype extension for the favicon tracking type.
+
+syntax = "proto2";
+
+option optimize_for = LITE_RUNTIME;
+option retain_unknown_fields = true;
+
+package sync_pb;
+
+// Tracking info for of favicon images. These control expiration of images
+// from sync based on recency, bookmark state, etc.
+message FaviconTrackingSpecifics {
+  // The url of the favicon image.
+  optional string favicon_url= 1;
+  // The last time a page using this favicon was visited (in milliseconds
+  // since linux epoch).
+  optional int64 last_visit_time_ms = 3;

[albertb, 2013/02/14 19:07:57]

Is this sane time? Might want to add that detail to the comment.

[Nicolas Zea, 2013/02/14 19:45:51]

It's kind of orthogonal I think. Either way we have to trust this value, since
we have no alternative.

+  // Whether this favicon is currently bookmarked or not.
+  optional bool is_bookmarked = 4;

[albertb, 2013/02/14 19:07:57]

I'm confused by this field. Isn't it trivial for the client to figure out which
URLs are bookmarked and thus which favicons should never be evicted? Why sync
this fact?

Is it to signal to non-bookmark syncing clients to not evict those favicons?

[Nicolas Zea, 2013/02/14 19:45:51]

Yes, it's primarily for non-bookmarking clients. Additionally, if someone just
added a bookmark, and the favicon reaches another client first, we don't want to
delete the favicon unnecessarily before the bookmark arrives. This will involve
a bit of logic client-side though, so that we don't wind up with a bunch of
favicons that we think are bookmarked but aren't actually (e.g. conflict
resolution somehow kept them around).

+}