Fixes expected results. GetDisabledReasons returns a different value
from Chromium because one of the sync preferences had the initial value
flipped.

Chromium change:

https://chromium.googlesource.com/chromium/src/+/84acadd70d0ef573faf775d712ba6cd430f931e2

commit 84acadd70d0ef573faf775d712ba6cd430f931e2
Author: Marc Treib <treib@chromium.org>
Date:   Mon Jul 8 16:02:25 2019 +0000

    SyncPrefs: Change default value of "IsSyncRequested" to false

    This is achieved by migrating the "SyncSuppressed" pref to a new
    "SyncRequested" pref.

    Before this CL, there was a pref called "sync.suppress_start", which was the
    inverse of the "IsSyncRequested" flag in SyncPrefs/SyncUserSettings. It was
    false by default, meaning Sync was considered "requested" even if the user
    had never even attempted to turn on Sync.

    This CL migrates the value over to a new "sync.requested" pref, which is the
    inverse of the old pref, and has the correct default value (not requested).

    If the old pref has an explicit value, then the migration is simply
    "sync.requested := !sync.suppress_start". If the old pref does not have a
    value, then there's generally nothing to migrate (and thus the implicit value
    of "IsSyncRequested" will change to false, which is the sane default state).
    However, as one special case of the migration, if the old pref is not
    explicitly set, but "IsFirstSetupComplete" is true, then that means Sync was
    actually enabled, but (probably through some past bug in the Sync setup flow)
    "SetSyncRequested(true)" was just never called. To correctly migrate users
    in this state, we set the new "sync.requested" pref to true.

    Apart from the migration edge case mentioned above, the different default
    value does not introduce a behavior change: All sync setup flows must anyway
    call SetSyncRequested(true) since they can't be sure what the previous value
    was.

    Bug: 906034