[WIP] QR codes and symmetric encryption for broadcast channels

[Hocuri]

Follow-up for #7042, part of #6884.

This will make it possible to create invite-QR codes for broadcast channels, and make them symmetrically end-to-end encrypted.

• Go through all the changes in [WIP] QR codes, symmetric encryption, and a new securejoin protocol for broadcast channels #7042, and check which ones I still need, and revert all other changes
• Use the classical Securejoin protocol, rather than the new 2-step protocol
• Make the tests pass
• Test it, and fix any bugs I find
• Create an issue that outlines how we can improve the Securejoin protocol in the future (I don't have the time to do this right now, but want to do it sometime in Winter)
• Write a guide for UIs how to adapt to the changes (see [WIP] feat: Adapt to channel-invite QR codes deltachat/deltachat-android#3886)

The symmetric encryption

Symmetric encryption uses a shared secret. Currently, we use AES128 for encryption everywhere in Delta Chat, so, this is what I'm using for broadcast channels (though it wouldn't be hard to switch to AES256).

The secret shared between all members of a broadcast channel has 258 bits of entropy (see fn create_broadcast_shared_secret in the code).

Since the shared secrets have more entropy than the AES session keys, it's not necessary to have a hard-to-compute string2key algorithm, so, I'm using the string2key algorithm salted. This is fast enough that Delta Chat can just try out all known shared secrets. ¹ In order to prevent DOS attacks, Delta Chat will not attempt to decrypt with a string2key algorithm other than salted ².

Footnotes

1. In a symmetrically encrypted message, it's not visible which secret was used to encrypt without trying out all secrets. If this does turn out to be too slow in the future, then we can assign a short, non-unique (~2 characters) id to every shared secret, and send it in cleartext. The receiving Delta Chat will then only try out shared secrets with this id. Of course, this would leak a little bit of metadata in cleartext, so, I would like to avoid it. ↩

2. A DOS attacker could send a message with a lot of encrypted session keys, all of which use a very hard-to-compute string2key algorithm. Delta Chat would then try to decrypt all of the encrypted session keys with all of the known shared secrets. In order to prevent this, as I said, Delta Chat will not attempt to decrypt with a string2key algorithm other than salted ↩

[Hocuri]

Leaving a broadcast channel now uses the same code as leaving a group, so, we don't need this block anymore.

See this code a few lines above:

    if matches!(
        chat.typ,
        Chattype::Group | Chattype::OutBroadcast | Chattype::InBroadcast
    ) {

[Hocuri]

I removed this block because we're in the else clause of if is_contact_in_chat(context, chat_id, contact_id).await?, so, this was dead code

[Hocuri]

I removed this line because above we're ckecking ensure!(chat.typ == Chattype::Group || chat.typ == Chattype::OutBroadcast [...]), so, this was dead code

[Hocuri]

This uses SEIPD v2, while in other places, we use SEIPD v1. I assume that we used SEIPD v1 because v2 didn't exist yet at the time, and SEIPD v2 is superior, so, we should use it?