[Sync] Add support for dynamically enabling/disabling types

sync/api/sync_error.h

 // Copyright 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef SYNC_API_SYNC_ERROR_H_
 #define SYNC_API_SYNC_ERROR_H_
 
 #include <iosfwd>
 #include <string>
 
@@ skipping 11 matching lines @@
 // exposed through Chrome's "about:sync" internal page.
 // This class is copy-friendly and thread-safe.
 class SYNC_EXPORT SyncError {
  public:
   // Error types are used to distinguish general datatype errors (which result
   // in the datatype being disabled) from actionable sync errors (which might
   // have more complicated results).
   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.
   SyncError();
 
   // Create a new Sync error of type |error_type| triggered by |model_type|
   // from the specified location. IsSet() will return true afterward. Will
   // create and print an error specific message to LOG(ERROR).
   SyncError(const tracked_objects::Location& location,
             ErrorType error_type,
@@ skipping 49 matching lines @@
   ModelType model_type_;
   ErrorType error_type_;
 };
 
 // gmock printer helper.
 SYNC_EXPORT void PrintTo(const SyncError& sync_error, std::ostream* os);
 
 }  // namespace syncer
 
 #endif  // SYNC_API_SYNC_ERROR_H_