[Sync] Add support for dynamically enabling/disabling types

sync/api/sync_error.h

Index: sync/api/sync_error.h
diff --git a/sync/api/sync_error.h b/sync/api/sync_error.h
index 306ed83fc72421b1bef249dfe04d6b2d4cc9b7ac..f6ffa87f3132c8c795bb60aeb00e6e81542c26b0 100644
--- a/sync/api/sync_error.h
+++ b/sync/api/sync_error.h
@@ -29,13 +29,17 @@ class SYNC_EXPORT SyncError {
   enum ErrorType {
     UNSET,                // No error.
     UNRECOVERABLE_ERROR,  // An unrecoverable runtime error was encountered, and
-                          // sync should be disabled completely.
+                          // sync should be disabled and purged completely.
     DATATYPE_ERROR,       // A datatype error was encountered, and the datatype
-                          // should be disabled.
+                          // should be disabled and purged completely. Note that
+                          // datatype errors may be reset, triggering a
+                          // re-enable.
     PERSISTENCE_ERROR,    // A persistence error was detected, and the
                           // datataype should be associated after a sync update.
     CRYPTO_ERROR,         // A cryptographer error was detected, and the
                           // datatype should be associated after it is resolved.
+    UNREADY_ERROR,        // The type is not ready to start yet, so should be

[stanisc, 2014/06/10 21:21:42]

I didn't quite understand whether this could be used later to explicitly disable
a datatype due to configuration constraints or user settings. If that is the
plan, should this error type be called differently, for instance DISABLED_ERROR?
UNREADY sounds like it could become ready at some point which probably isn't the
case for types that are disabled by constraints.

[Nicolas Zea, 2014/06/19 00:04:22]

I'm open to other names, but note that the type being disabled is different than
this error. If the type is disabled, we'll actively purge it everywhere. Unready
errors imply that some run time constraint has not been met, but once it does we
will be syncing the type again. In that case, don't purge it at this time.

In other words, when you go into user settings and explicitly disable the type,
a different code path will be used that the one involving this error.

+                          // neither purged nor enabled until it is ready.
   };
 
   // Default constructor refers to "no error", and IsSet() will return false.