Account switching migration service

[mpbw2]

Type of change

• Bug fix
• New feature development
• Tech debt (refactoring, code cleanup, dependency upgrades, etc)
• Build/deploy pipeline (DevOps)
• Other

Objective

Migrate existing user data to the new multi-account storage pattern upon app update.

Code changes

• MainApplication.cs: Init StateMigrationService with the required storage services
• LockPage.xaml.cs: Remove avatar appearance condition since it will always been shown here
• GroupingsPage.xaml.xs: Remove old v1-to-v2 migration code (some of which was moved to StateMigrationService)
• BaseContentPage.cs: Change avatar appearance condition to the presence of any active account, which should only ever be false before the very first login
• MobileStorageService.cs: Remove old migration keys & logic, add key for state version
• AppIdService.cs: Reverted to pre-multi-account state due to infinite loop during migration when it was using the state service (this particular value isn't user-specific so it's ok if it isn't managed by the state service)
• StateMigrationService.cs: Service that performs the migration. As the mobile app had a previous migration, that was moved here as the "1 to 2" migration. The multi-account migration was added as "2 to 3".
• StateService.cs: Removed unused methods, added migration check and trigger, changed ProtectedPin to default storage (was never in secure storage), changed account removal to clean house since it felt dirty to have settings restored when logging back in after previously removing an account (doesn't apply to logout as a vault timeout action), set new account theme to the current theme to avoid the jarring effect of possible theme change when adding a new account
• ServiceContainer.cs: Restore storageService to appIdService
• Constants.cs: Add/remove appropriate keys
• iOSCoreHelpers.cs: Init StateMigrationService with the required storage services

Testing requirements

Create account with previous (non-account-switching build) then update to account switching build and confirm all data and settings is still intact

Before you submit

• I have added unit tests where it makes sense to do so (encouraged but not required)
• This change requires a documentation update (notify the documentation team)
• This change has particular deployment requirements (notify the DevOps team)

[fedemkr]

I think it looks good, but I would split the StateMigrationService into the service coordinator itself and each migration in a different file:
StateMigrationFrom1To2.cs and StateMigrationFrom2To3.cs so that we have more cohesion on what each class has and does and the service just stays there as a coordinator between the different migrations. Furthermore, it prevents the file to be gigantic when more migrations are added, and to be more organized. Maybe I'm over-engineering this at this point and this could be looked at when we have more migrations, what do you think?

[mpbw2]

Makes sense though I doubt we'll see a migration of this magnitude again any time soon. I'm for revisiting when it's time for another migration.