[Sync] Add ability to save/restore Nigori to SyncEncryptionHandlerImpl

sync/internal_api/public/sync_encryption_handler.h

Index: sync/internal_api/public/sync_encryption_handler.h
diff --git a/sync/internal_api/public/sync_encryption_handler.h b/sync/internal_api/public/sync_encryption_handler.h
index bf5a6efe80c1061b0b24169db0cd5573bef6c76a..43423e18e707b236cafd9954bb959907165cb426 100644
--- a/sync/internal_api/public/sync_encryption_handler.h
+++ b/sync/internal_api/public/sync_encryption_handler.h
@@ -10,10 +10,7 @@
 #include "base/time/time.h"
 #include "sync/base/sync_export.h"
 #include "sync/internal_api/public/base/model_type.h"
-
-namespace sync_pb {
-class EncryptedData;
-}
+#include "sync/protocol/sync.pb.h"
 
 namespace syncer {
 
@@ -56,6 +53,8 @@ enum BootstrapTokenType {
 // methods must be invoked on the sync thread.
 class SYNC_EXPORT SyncEncryptionHandler {
  public:
+  struct NigoriState;
+
   // All Observer methods are done synchronously from within a transaction and
   // on the sync thread.
   class SYNC_EXPORT Observer {
@@ -123,10 +122,22 @@ class SYNC_EXPORT SyncEncryptionHandler {
     virtual void OnPassphraseTypeChanged(PassphraseType type,
                                          base::Time passphrase_time) = 0;
 
+    // The user has set a custom passphrase using this device.
+    //
+    // |nigori_state| can be used to restore nigori state across
+    // SyncEncryptionHandlerImpl lifetimes. See also SyncEncryptionHandlerImpl's
+    // RestoredNigori method.
+    virtual void OnLocalSetCustomPassphrase(
+        const NigoriState& nigori_state) = 0;
+
    protected:
     virtual ~Observer();
   };
 
+  struct NigoriState {
+    sync_pb::NigoriSpecifics nigori_specifics;

[Nicolas Zea, 2015/06/11 17:43:07]

Do you expect to persist any other information as part of this struct? Does it
make more sense to just pass the specifics (or even a string with the serialized
data)?

[maniscalco, 2015/06/15 16:49:18]

Currently, I think the NigoriSpecifics is all I will need.  In a previous
iteration I was passing around an EntryKernel as well (but realized I didn't
need it).  It was handy having the struct because this interface is implemented
in a bunch of places so changing the signature is a pain (gotta update a lot of
code to to change the parameter type or add a second param).

IMO, having a dedicated type here seems like the right thing because it will
allow us to hide some of the details from users of SyncEncryptionHandler.  WDYT?

+  };
+
   SyncEncryptionHandler();
   virtual ~SyncEncryptionHandler();