On Android the flag that sync is enabled is stored in two places:
  - In Android's ContentResolver (accessed from Chrome through AndroidSyncSettings): User should be able to control Chrome sync from Android settings. In addition user should be able to disable sync with master sync switch. Chrome typically is not running during user interactions with settings.
  - In Chrome preferences: This is the primary location on all platforms other than Android. Preference is controlled by ProfileSyncService.

SyncController is the class that synchronizes above two locations: 
  - It propagates AndroidSyncSettings to sync engine on startup (because user could have modified settings while Chrome wasn't running).
  - It then listens for notifications from both AndroidSyncSettings and ProfileSyncService and propagates modifications to the other side. This way when user disables sync in Android settings while Chrome is running, the change causes ProfileSyncService to stop. Conversely when ProfileSyncService receives signal from server that sync should be disabled (DSaC) this change gets propagated to Android setting UI.

Since SyncController instantiation is delayed, configuration values can get out of sync. Here is potential scenario:
  - Chrome starts up, detects that sync is enabled and starts sync engine. 
  - Response from server (NOT_MY_BIRTHDAY) indicates that sync should be disabled. Which causes ProfileSyncService::RequestStop().
  - Later when SyncController is instantiated in GoogleServicesManager it notices that sync engine is disabled while AndroidSyncSettings indicate that sync should gbe enabled and restarts sync.

Ideally it would be nice to have single source of truth for "sync is enabled" flag. This would avoid inconsistencies. For this we need to route server's "stop syncing" signal through AndroidSyncSettings. Unfortunately this makes more brittle, bug prone design.