Not for review: Support sync init with missing or corrupt store

NOTE: This patch can be rolled into some of Nicolas' 
configuration refactoring work.  I'll keep it around so we 
can use it as a reference, but it's unlikely that it will 
ever be committed.  

===============

Support sync init with missing or corrupt store

Although the sync code did already support this, the solution came with
a big TODO comment and the potential for some nasty side-effects.
That's a big part of the reason why we did not try to recover from
database corruption; it was safer to just sign out the user to avoid
creating even worse problems (ie. DCHECK violation or crash).

The old code assumed that information in the prefs store was in sync
with the data in the sync database.  This assumption would not be
verified until the configure step that follows
ProfileSyncService::OnBackendInitialized(), leaving sync in an
inconsistent during and immediately following backend initialization.

This patch will return information about the list of types found in the
database during the first step of backend initialization.  This allows
the backend to know its own state.  SyncBackendRegistrar's type
information will be in sync with the contents of the sync database.
When the configure following OnBackendInitialize does occur, the
database will be configured to match the preferred types.  The backend
does not require any special code to handle the case where the database
does not already match the user's preferences.

Because we can now trust the sync initialization process to behave
correctly even if it does unexpectedly receive an empty database, it is
now safe to delete a corrupt directory and replace it with a new one.
The user's data will need to be re-downloaded, but there's not much we
coud do to avoid that.

BUG=129825, 109668
TEST=Manual:
- Delete 'Sync Data/SyncData.sqlite3' from profile directory.  Verify
  that the client re-downloads its synced state on startup.
- Corrupt the sync database with sqlite.  For example, use the command
  'DELETE FROM metas WHERE metahandle = 1'.  Restart the client and
  verify that the corruption is detected, the database is deleted and
  the sync data re-downloaded into a new database.

[rlarocque, 2012-06-04 20:07:09]

Here is the long-awaited directory corruption handling patch.  Please review.

It's a big diff, but a lot of it is either noise generated by changing function
signatures, or changes to the unit tests.  The most interesting parts are in
SyncBackendRegistrar, SyncBackendHost and SyncManager (especially
SyncManager::SyncInternal::OpenDirectory()).

I'm not very happy with the way the test functions worked out, but I think our
coverage is still fairly good.  Hopefully we can improve our coverage as we
start to clean up the TestProfileSyncService.

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
File chrome/browser/sync/glue/sync_backend_host.h (right):

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
chrome/browser/sync/glue/sync_backend_host.h:370:
scoped_ptr<PendingConfigureDataTypesState> pending_download_state_;
The moves in this file were necessary to make pending_download_state_ and
pending_config_mode_state_ protected instead of private, so they could be
accessed by the unit tests.

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
File chrome/browser/sync/glue/sync_backend_registrar.cc (right):

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
chrome/browser/sync/glue/sync_backend_registrar.cc:91: // Set our initial state
to reflect the current status of the sync directory.
I could use a flag and some DCHECKs to ensure that this function is called only
once and is called before any other public method.  I'm not convinced that would
be a good idea, though.  Thoughts?

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
File chrome/browser/sync/glue/sync_backend_registrar.h (right):

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/glue/sy...
chrome/browser/sync/glue/sync_backend_registrar.h:59: void
SetInitialTypes(syncable::ModelTypeSet initial_types);
I'm not a fan of this two-stage init.  It may be possible to split this class in
two in order to avoid this, but I haven't tried.  

On the plus side, this is much simpler and safer than the other schemes I tried.
 There's no need for extra inter-thread communication with this approach.  That
does a lot to reduce the amount of new code and error-handling required.

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/profile...
File chrome/browser/sync/profile_sync_service_unittest.cc (left):

http://codereview.chromium.org/10520010/diff/2001/chrome/browser/sync/profile...
chrome/browser/sync/profile_sync_service_unittest.cc:366:
TEST_F(ProfileSyncServiceTest, DISABLED_CorruptDatabase) {
Our test framework actually makes this really hard to test.  Even if I could
generate an error, there are flags in SyncManager used to ignored errors in the
SignIn() function when the SM is in "test mode".  We're a long way away from
being able to unit test this error path.

http://codereview.chromium.org/10520010/diff/2001/sync/syncable/directory_bac...
File sync/syncable/directory_backing_store_unittest.cc (left):

http://codereview.chromium.org/10520010/diff/2001/sync/syncable/directory_bac...
sync/syncable/directory_backing_store_unittest.cc:2089:
TEST_F(DirectoryBackingStoreTest, DISABLED_Corruption) {
I've given up on testing this.  I simply can't find a way to trigger the right
kind of failure.  All my attempts are either unable to trigger an error, or
cause a CHECK failure in the SQL code.