chore: remove session manager completion handlers - WPB-23401

[samwyndham]

Issue

This PRs converts a number of UserSession methods with completion handlers to async methods. Necessarily this requires small changes in behavior that are hard to understand due to for example the addition of Task in various places which may slightly change the order of execution. I've tried to look at where these have been added and think it is safe (often it is in a kind of fire and forget context) but these changes should be well tested.

Testing

These are not specific test steps but more scenarios

• Login multiple accounts on a couple of different backends
• Switch between different accounts.
• Logging out
• Cancel logging out of one account when logged in with multiple
• Switch backend from the conversation list & login.
• Using simulator, log in to multiple accounts, then simulate a memory warning in the simulator menu, then switch accounts.
• Have multiple logins, Enable 'createLegacyBackups', create a backup, logout, rel-ogin, restore, switch accounts a few times.
• Login with production + staging, select staging, go Dev tools > Overrides, enter staging for the obsolete backend, app restarts, error is shown - select switch accounts to go to production.
• Answer a a call to a non active account

Legacy authentication:

• Cancel logging in a second account using legacy authentication (x button)

---

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.
• Adds/updates automated tests.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Test Results

2 979 tests   2 952 ✅  3m 27s ⏱️
  435 suites     27 💤
    2 files        0 ❌

Results for commit 58b7054.

Summary: workflow run #22055786101
Allure report (download zip): html-report-27849-chore_remove-session-manager-completion-handlers-WPB-23401

[johnxnguyen]

thought: not really part of the scope here but I'm curious to see what you think. Calling this method will ask a ui delegate to present an alert and request user confirmation. Do you think this kind of back and forth communication makes sense? Or would it be better to have a single direction: ui tries to select an account, if confirmation is needed, throw error, ui handles, gets confirmation, tries again passing in a confirmation flag. Something liKe:

public func select(_ account: Account, authoritative: Bool) async throws -> ZMUserSession? {
  if confirmationNeeded && !authoritative  {
    throw Error.confirmationNeeded
  }

  // continue...
}

[johnxnguyen]

suggestion: if you follow the path delegate.sessionManagerWillOpenAccount you'll see that it does nothing but immediately invoke the userSessionCanBeTornDown completion handler. I think you can simplify this by removing the delegate method as well as the AppState.loading case.

[johnxnguyen]

question: why not make delete(account:reason:eraseData) async?