fix(mls): set removal-keys for 1on1 calls from conversation-response (WPB-10743)

[mchenani]

---

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?

Fetch and set removal-keys from the create-conversation response for 1on1 conversations and only APIV6

Testing

Test Coverage (Optional)

• I have added automated test to this contribution

---

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 065 tests   2 958 ✔️  3m 29s ⏱️
   524 suites     107 💤
   524 files           0 ❌

Results for commit 057dde2.

♻️ This comment has been updated with latest results.

[datadog-wireapp]

Datadog Report

All test runs f609b6c 🔗

✅ 2 Total Test Services: 0 Failed, 2 Passed

Test Services

Service Name	Failed	Known Flaky	New Flaky	Passed	Skipped	Total Time	Test Service View
kalium-ios	0	0	0	2805	123	1.41s	Link
kalium-jvm	0	0	0	2958	107	6.55s	Link

[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 SonarCloud

[MohamadJaara]

question: there are places where this function is called with null and defaulting back to the server keys, mainly JoinExistingMLSConversationUseCaseImpl, MLSMigrator is this expected and what are the potential consciences of this, will it go back to the 50% chance of stuff being broken?
@mchenani

[mchenani]

The prekeys we get from the conversation response only needed when we want to create a conversation, there is no need to do so when we joining the existing conversations.

[MohamadJaara]

will take any further discussions to 1:1