[Sync] Calculate active types and track catch up in DTMI not PSS.

components/browser_sync/profile_sync_service.h

Index: components/browser_sync/profile_sync_service.h
diff --git a/components/browser_sync/profile_sync_service.h b/components/browser_sync/profile_sync_service.h
index 43c8f8bb7949c0c5b59a8edc8368ac970b256026..6275c2e6cbbdbc8dedb49bf4a21f452c744e56ed 100644
--- a/components/browser_sync/profile_sync_service.h
+++ b/components/browser_sync/profile_sync_service.h
@@ -937,12 +937,6 @@ class ProfileSyncService : public syncer::SyncServiceBase,
   std::unique_ptr<syncer::SyncEncryptionHandler::NigoriState>
       saved_nigori_state_;
 
-  // When BeginConfigureCatchUpBeforeClear is called it will set
-  // catch_up_configure_in_progress_ to true. This is needed to detect that call
-  // to OnConfigureDone originated from BeginConfigureCatchUpBeforeClear and
-  // needs to be followed by ClearAndRestartSyncForPassphraseEncryption().
-  bool catch_up_configure_in_progress_;

[pavely, 2017/01/26 18:02:51]

I don't think we should move this field to DTM. Having this field in PSS allows
to trace logic without reviewing implementation of DTMI. By moving it to DTM you
force reader to grok details of DTM to understand logic in PSS. Does presence of
this field in PSS hinders your encryption related refactoring?

[maxbogue, 2017/01/26 18:41:39]

It does, because one function I want to move out of PSS triggers a catch up
configure and currently sets the PSS flag. I don't think it's particularly
complicated to understand that the "was_catch_up_configure" field on a
ConfigureResult will be true if the configure was a catch up configure, is it?
There's really no reason we should be storing "we're doing a catch up configure"
in two different places...

-
   // Whether the major version has changed since the last time Chrome ran,
   // and therefore a passphrase required state should result in prompting
   // the user. This logic is only enabled on platforms that consume the