sync: Follow-up to conflict resolution refactor

sync/protocol/get_updates_caller_info.proto

Index: sync/protocol/get_updates_caller_info.proto
diff --git a/sync/protocol/get_updates_caller_info.proto b/sync/protocol/get_updates_caller_info.proto
index c921a8ded0b8f2c536139a64ff2d684f90246a0a..86fe9c83fbcb6467528d08270b429361b91d4dd8 100644
--- a/sync/protocol/get_updates_caller_info.proto
+++ b/sync/protocol/get_updates_caller_info.proto
@@ -18,7 +18,8 @@ message GetUpdatesCallerInfo {
     NOTIFICATION = 3;  // The source of the update was a p2p notification.
     PERIODIC = 4;  // The source of the update was periodic polling.
     SYNC_CYCLE_CONTINUATION = 5;  // The source of the update was a
-                                  // continuation of a previous update.
+                                  // continuation of a previous sync cycle.
+                                  // No longer sent as of M24.

[tim (not reviewing), 2012/10/26 22:44:06]

Hmm.  I think we should still use this to denote cycles that occur due to
CONFLICT return codes.  We're using exponential backoff right now for those
cases, but that's out of convenience.  We should not backoff exponentially for
conflict errors, we should just retry.  And I could see it being useful to
distinguish those GetUpdates.  

[rlarocque, 2012/10/31 23:48:20]

As discussed offline, I think it would be better to use a different value for
that purpose.  The newer clients would be scheduling those jobs based on
different reasoning.  They should use a new enum value to make it clear that's
what they are doing.  

 
     // This value is deprecated and was never used in production.
     // CLEAR_PRIVATE_DATA = 6;