chore: bulletproofing crypto box to cc migration (WPB-14250) (🍒4.6)

[yamilmedina]

WPB-14250 [Android] implement fall guards for CC migration

This PR was automatically cherry-picked based on the following PR:

• chore: bulletproofing crypto box to cc migration (WPB-14250) #3123

Original PR description:

---

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

When enabling core crypto storage, if there are any Proteus clients, we need to migrate them from CryptoBox.
Things usually don't go as planned, so we need to have a recovery plan in place.

Causes (Optional)

There might be some errors while migrating.

Solutions

Implement a recovery plan for this case:

• Catch possible exceptions from migration, we were not handling it and assuming success
• Perform logout, using a new LogoutReason, so we can act (cleanup) accordingly
  • Cleanup local crypto files
  • Cleanup from Metadata all related client info (retained id, current id, prekeys, etc.)
  • Set the refresh token to needs update.

If everything goes smoothly, the user will be prompted to login again, preserving their local history.

Dependencies (Optional)

• chore: bulletproofing crypto box to cc migration (WPB-14250) (🍒4.6) wire-android#3677

Needs releases with:

• GitHub link to other pull request

Testing

Test Coverage (Optional)

• I have added automated test to this contribution

Notes (Optional)

Note

This approach seems "more correct", since if we try to create a new device only -as the ticket suggested- we will run into the issue of the refresh token not being valid anymore, since it was associated with the broken client that we were trying to migrate. And we can't associate the previous refresh token with a different client, we get a 403.

• We will avoid other edge cases that we might not sure.
• All login cases will be covered (2FA, SCIM, etc.)
• We can expand this handling in the future (if we want) to other cases that we want to recover.

---

PR Post Submission Checklist for internal contributors (Optional)

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[github-actions]

Test Results

3 074 tests   2 966 ✔️  2m 47s ⏱️
   526 suites     108 💤
   526 files           0 ❌

Results for commit 69a2fda.

♻️ This comment has been updated with latest results.

[datadog-wireapp]

Datadog Report

All test runs 0b72ab5 🔗

❌ 2 Total Test Services: 1 Failed, 1 Passed

Test Services

Service Name	Failed	Known Flaky	New Flaky	Passed	Skipped	Total Time	Test Service View
kalium-jvm	1	0	0	2931	54	26.58s	Link
kalium-ios	0	0	0	2812	123	2.26s	Link

❌ Failed Tests (1)

• givenGettingOrCreatingAProteusClient_whenMigrationPerformedAndFails_thenCatchErrorAndStartRecovery[jvm] - com.wire.kalium.logic.data.client.ProteusClientProviderTest - Details

  Expand for error

   io.mockative.InvalidExpectationError: A function was called without a matching expectation.
   
       A coroutine stub was expected, but a blocking stub was configured on the function:
           PassphraseStorageMock.getPassphrase(proteus_db_secret_alias_41d2b365-f4a9-4ba1-bddf-5afb8aca6786@domain)
   
       Set up an expectation using:
           given(instance).invocation { getPassphrase(proteus_db_secret_alias_41d2b365-f4a9-4ba1-bddf-5afb8aca6786@domain) }
               .then { ... }
       
       The following expectations were configured on the mock:
   ...
  

[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