sync: Support non-blocking initial sync in proto

sync/protocol/sync.proto

Index: sync/protocol/sync.proto
diff --git a/sync/protocol/sync.proto b/sync/protocol/sync.proto
index 276824272fe2f7835fa37389243dc885f5b99907..c66e25e62cd61d106b42678d5e3d18259112967c 100644
--- a/sync/protocol/sync.proto
+++ b/sync/protocol/sync.proto
@@ -477,6 +477,17 @@ message GetUpdateTriggers {
   // This flag is set if the invalidation server reports that it may have
   // dropped some invalidations at some point.  Introduced in M33.
   optional bool server_dropped_hints = 6;
+
+  // This flag is set if this GetUpdate request is due at least in part due
+  // to the fact that this type has not finished initial sync yet, and the
+  // client would like to initialize itself with the server data.
+  //
+  // Only some types support performing an initial sync as part of a normal
+  // GetUpdate request.  Many types must be in configure mode when fetching
+  // initial sync data.
+  //
+  // Introduced in M38.
+  optional bool initial_sync_in_progress = 7;

[Nicolas Zea, 2014/07/17 16:58:08]

I wonder, should we specify which types are requesting the initial sync? It
might be useful for the backend to e.g. know which backing stores it actually
needs to hit.

[rlarocque, 2014/07/17 18:58:06]

The triggers are per-type.  I think they're co-located with the progress
markers.

All the data required to gather per-type stats are here.  Whether or not it's
easy to turn it into useful graphs on the server may be another matter, though.

 }
 
 message GarbageCollectionDirective {