We retain Fennec's preferences on disk, so re-running this migration will
make sure that marketing/experiments settings in Fenix correspond to the FHR setting
in Fennec (they'll be turned off if FHR settings is 'off', and left 'on' if FHR is 'on').

For the users running this migration for the first time, it's just a regular migration.

For the users who already ran this migration, we will re-align data collections settings around
their choices in Fennec.

The log messages themselves are not actionable and just add nosie to Sentry. We collect the same
information via telemetry and that gives us a much better view of the success/failure distribution.

This fixes fallback from https://github.com/mozilla-mobile/android-components/pull/6395 in which
FennecMigrator changed to accept a Lazy-wrapped reference to the account manager.

This was done so that during regular (non-migrating) startup, a simple act of building a no-op
migrator will not cause account manager initialization.

However, during a migrating startup this creates a race to initialize account manager.
Two participants in this race are:
1) FenixApplication running expensive operations (such as storage init, account manager init)
after visual completeness. However, currently that just entails a 5 second delay from `onStart`.
2) FxA migration, which runs roughly at the mid-point of the migration.

Account manager currently can't be initialized on a background thread (or it will crash).
FxA migration runs on a background thread, so if (2) wins (that is, migrations before FxA migration take
less than 5 seconds), then migration will crash.

This patch adds an eager initialization right before we kick-off migrations but are still on the main thread,
iff an FxA migration will be executed.

This is to re-run the add-on migration step to correct
for https://bugzilla.mozilla.org/show_bug.cgi?id=1623173
which left add-ons in an inconsistent state after the
upgrade to 76 Nightly.

This refactor changes how (most) consumers are expected to interact with the logins storage.
Instead of "locking"/"unlocking" the store whenever its needed, a connection to a storage
layer is now cached on first access and re-used for subsequent operations.

Various components relying on logins storage have been simplified.

Currently a notification is being shown for migration progress status, but no notification is being
displayed to the user for when the migration is complete.
In order to properly handle this notification's remove or click action, a broadcast receiver is
required that listens for this specific actions so it can remove the notification's channel.

This also adds some missing FxA failure telemetry, as well.

FennecMigrator: Notify Glean about whether telemetry should be collected after migrating Fennec setting.

This refactors login migration code to make sure any crashes do not affect the running migration.

This patch introduces a new "FennecSettingsMigrator" which will be responsible
for migrating all common Fennec - Fenix settings.

Starting with the telemetry opt-in status which in Fenix will be "true" if the
Firefox Health Report setting ws also true on Fennec, and "false" otherwise.
It may be possible that the Fenix install is a new one and not an upgrade from
Fennec in which case no setting will be migrated and the migration would be
considered as successful.
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

We are logging exceptions when no profile is found, which is actually a legit case.
There will be no profile on a fresh install, for example.

This patch makes these kinds of exceptions more precise/useful: we'll only send a report
in case there's a profile but a missing dbPath. We'll now also send an exception in case
of an IOException while parsing profiles.

This adds basics of the Fennec Firefox Account state migration, bailing
out if we're not processing v4 fxa state.

Migration is done from the "pickle file". Cleaning up system account is TBD.