sync: Add non-blocking type encryption support

sync/engine/entity_tracker.h

Index: sync/engine/entity_tracker.h
diff --git a/sync/engine/entity_tracker.h b/sync/engine/entity_tracker.h
index db2d09bf3cf349841ecdb4102e5a30ebb234b043..96fb5bd7a9d733103dc56f9acee1664b005db98f 100644
--- a/sync/engine/entity_tracker.h
+++ b/sync/engine/entity_tracker.h
@@ -8,8 +8,10 @@
 #include <string>
 
 #include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
 #include "base/time/time.h"
 #include "sync/base/sync_export.h"
+#include "sync/internal_api/public/non_blocking_sync_common.h"
 #include "sync/protocol/sync.pb.h"
 
 namespace syncer {
@@ -81,6 +83,21 @@ class SYNC_EXPORT EntityTracker {
   // Handles receipt of an update from the server.
   void ReceiveUpdate(int64 version);
 
+  // Handles the receipt of an inapplicable update from the server.
+  //
+  // Returns true if the tracker decides this item is worth keeping.  Returns
+  // false if the item is discarded, which could happen if the version number
+  // is out of date.
+  bool ReceiveInapplicableUpdate(const UpdateResponseData& data);
+
+  // Functions to fetch the latest inapplicable update.
+  bool HasInapplicableUpdate() const;
+  UpdateResponseData GetInapplicableUpdate() const;
+
+  // Clears the inapplicable update.  Allows us to resume regular commit
+  // behavior.
+  void ClearInapplicableUpdate();
+
  private:
   // Initializes received update state.  Does not initialize state related to
   // pending commits and sets |is_commit_pending_| to false.
@@ -146,6 +163,10 @@ class SYNC_EXPORT EntityTracker {
   bool deleted_;
   sync_pb::EntitySpecifics specifics_;
 
+  // An update for this item which can't be applied right now.  The presence of

[stanisc, 2014/07/30 00:30:04]

"Inapplicable" sounds to me like it can't be applied at all. If this can't be
applied right now but could be applied later, perhaps, it should be called
differently. How about "pending"?

Also in another file you mentioned that inapplicable updates are usually caused
by a temporary decryption failure. How about mentioning that here as well?

[rlarocque, 2014/07/30 21:56:01]

Nicolas mentioned that he might need to the concept of "inapplicable updates"
for a different feature.  I'll let him comment on this.

If forward-compatibility is not a concern, then I would advocate calling them
simply "undecryptable updates".
Done.

[Nicolas Zea, 2014/07/31 18:06:26]

Eventually we want to support datatype specific conflict resolution, wherein an
update can remain unapplied while the datatype itself decides how the conflict
should be resolved. In that case, I think it makes sense to keep those updates
around as updates that could not be applied. 

Something like pending_updates is fine though. Undecryptable updates will remain
pending until the key is provided.

[rlarocque, 2014/07/31 18:54:04]

Done.  Renamed all instances of inapplicable to pending throughout the CL.

+  // an inapplicable update prevents commits.
+  scoped_ptr<UpdateResponseData> inapplicable_update_;
+
   DISALLOW_COPY_AND_ASSIGN(EntityTracker);
 };