[WIP] feat: Securejoin v3, encrypt all securejoin messages

[Hocuri]

Close #7396

TODO:

• Implement the new protocol
• Make Rust tests pass
• Make Python tests pass
• Test it manually on a phone
• Print the sent messages, and check that they look how they should: test_secure_join_group_with_mime_printed.txt
• Fix bug: If Alice has a second device, then Bob's chat won't be shown yet on that second device. Also, Bob's contact isn't shown in her contact list. As soon as either party writes something into the chat, the that shows up and everything is fine. All of this is still a way better UX than in WhatsApp, where Bob always has to write first 😂 Still, I should fix that.
  • This is actually caused by a larger bug: AUTH tokens aren't synced if there is no corresponding INVITE token.
• Either make a new auth_tokens table with a proper UNIQUE bound, or put a UNIQUE bound on the tokens table
• Benchmarking
• TODOs in the code, maybe change naming of the new functions
• Write test for interop with older DC (esp. that the original securejoin runs if you remove the &v=3 param)
• Documentation
• From a cryptography perspective, is it fine that vc-request is encrypted with AUTH, rather than a separate secret (like INVITE)?
• Make sure that QR codes without INVITE work, so that we can remove it eventually
• Update tests and other code to use the new names (e.g. request-pubkey rather than request and pubkey rather than auth-required - Could be done in a follow-up

Backwards compatibility:
Everything works seamlessly in my tests. If both devices are updated, then the new protocol is used; otherwise, the old protocol is used. If there is a not-yet-updated second device, it will correctly observe the protocol, and mark the chat partner as verified.

[Hocuri]

TODO use a new table rather than reusing AUTH token. Sort it by id DESC, in order to try the most recently generated token first.

[Hocuri]

Actually, not sure if that's worth it.

We need to be able to look up existing AUTH tokens in case someone scans a QR code that was generated before the upgrade. So, token::exists would need to check both tables.

At this point, the question is, why make a new table at all.