commit e0f6a08548723bfbb823dd2b4d2f37ace5926957
author Mikel Astiz <mastiz@chromium.org> Fri Sep 22 18:26:02 2023
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Sep 22 18:26:02 2023
tree 61cf2869f774e89017e9c325e8fbb63cfe280dfe
parent 785e40b292d7769cbd27cbc78f173f434e3375b6

[sync] Clean up feature SyncIgnoreSyncRequestedPreference

No behavioral changes, other than cleaning up a feature flag that has
been enabled by default for some time.

The one non-trivial part to reason about is handling
IsSyncClientDisabledByPolicy(), which explicitly caused
IsSyncFeatureConsideredRequested() to return false before this patch but
may return true afterwards.

However, looking closely enough to the 4 calling sites, it is possible
to conclude that there aren't behavioral changes:
1) CanSyncFeatureStart(): verifies that GetDisableReasons() is empty,
   which wouldn't hold true due to DISABLE_REASON_ENTERPRISE_POLICY.

2) SyncServiceImpl initialization, when termining whether deferred
   startup should be used: it is unreachable because
   IsEngineAllowedToRun() would have returned false, for the same
   reason as above.

3) SyncServiceImpl initialization, when logging a metric via
   RecordSyncInitialState(): although the value for parameter
   `is_sync_feature_requested` may become true, internally the function
   only consumes this bit if GetDisableReasons() is empty, hence it is
   similar to the above.

4) SyncServiceImpl::IsSyncFeatureDisabledViaDashboard(), which may
   have incorrectly reported true before this patch. But it makes no
   difference in practice, because the only calling site in
   sync_ui_util.cc first verifies DISABLE_REASON_ENTERPRISE_POLICY.

Change-Id: I4c43e54291508d629b10d14b3948903ffc54b45f
Bug: 1219990
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4886256
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Ankush Singh <ankushkush@google.com>
Cr-Commit-Position: refs/heads/main@{#1200366}