commit 527d0a1ecb3ff4daf5c7ddd5316944df505d2f61
author Mikel Astiz <mastiz@chromium.org> Fri Sep 22 12:05:35 2023
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Sep 22 12:05:35 2023
tree e052f384bed7be123d872c9da51c63317a988bcd
parent 571efc14a068411df51daed09c1fcdbc47738da3

[sync] Decouple deferred initialization from unrelated prefs

Namely, IsInitialSyncFeatureSetupComplete() is about the user having
completed the procedure to turn sync on (including, if applicable, the
advanced sync settings page).

This concept has nothing to do with deferred startup, and influencing
one with another is very questionable. Moreover, the semantics for
IsInitialSyncFeatureSetupComplete() have no real meaning in the two
scenarios that exercise the modified code in SyncServiceImpl::Initialize(), that is, the two scenarios represented
by ShouldAutoStartSyncFeature()=true:
1) Local-sync, which doesn't require a user action to turn on the sync
   machinery.
2) ChromeOS Ash, which is similar from this point of view because the
   required user actions are taken in a platform-specific way and
   before SyncService is created.

This patch refactors the implementation to be less hacky, with minor
behavioral differences. This is because transport data is cleared more
often than the IsInitialSyncFeatureSetupComplete bit, namely in
all codepaths using DISABLE_SYNC_AND_CLEAR_DATA, which newly includes
unrecoverable errors and STOP_SYNC_FOR_DISABLED_ACCOUNT (enterprise
use-case).

Theoretically, this could lead to additional traffic to the server, but
in practice this is deemed negligible.

Change-Id: I81960343c5ca6dcb2d880ba51d20e7d9b311a3bd
Bug: 1445931, 1374718
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4882386
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200159}