feat: add secondary verified key

[link2xt]

When a key is gossiped for the contact in a verified chat,
it is stored in the secondary verified key slot.

The messages are then encrypted to the secondary verified key
if they are also encrypted to the contact introducing this secondary key.

Chat-Group-Member-Added no longer updates the verified key.
Verified group recovery only relies on the secondary verified key.

When a message is received from a contact
signed with a secondary verified key,
secondary verified key replaces the primary verified key.
When verified key is changed for the contact
in response to receiving a message
signed with a secondary verified key,
"Setup changed" message is added
to the same chat where the message is received.

Fixes #4541

[hpk42]

moving secondary keys-approach to resurrection -- let's discuss sometime if we still need them, in context of https://github.com/deltachat/securejoin/blob/main/uxscenarios/resetup.md

[link2xt]

Moving out of the project resurrection.

Without the secondary key if we allow "Member added" message to overwrite both the verified key and autocrypt key, an attacker who has a verified chat with the bot can create a verified group with the bot and a victim and start changing the key of the victim for the bot by constantly "adding" the victim to a verified group. An attacker may even send the message only to the bot (add only the bot in RCPT TO) and send "member removed" immediately afterwards so the bot leaving the groups will not notify the victim about the existence of the group. This would break all the communication of the victim and the bot.

If an attacker can only change the secondary key of the victim for the bot and the bot uses secondary key only in groups shared between the victim and the attacker, chats where the attacker is not present (1:1 chat and groups for which the attacker does not know the group ID) will not be affected.

[hpk42]

isn't this an introducer? Just because someone introduces a verified key does not make them the verified of that key so i think "introducer" is better, and also matches UI.

[link2xt]

This field was simply moved around the struct. But yes, we can rename everything in a single commit on top of this adding a migration and renaming all the columns.

[hpk42]

this PR introduces several new names and columns on the Rust-level -- didn't mean to suggest to rename existing database columns. But if you think database/rust-code consistency is more important than UI/core-naming then at least don't say "the address that verified this key" in a new doc comment because that's not the true meaning.

[link2xt]

I fixed the comments where possible.

[hpk42]

this looks good to me so far apart from the "verified" naming, which should be globally "introducer" (EDIT: not so important, but at least clarify things in the doc comments then).

[link2xt]

Chat-Group-Member-Added recovery test now also works without actually looking at the header.

[link2xt]

Here we should do something similar to peerstate.handle_setup_change but without AEAP, just directly iterate over all chats with the contact and spam stock_str::contact_setup_changed(context, &self.addr).await.

[hpk42]

lgtm -- i would probably let the python test have some "lp.sec(...)" section titles to allow debugging the test better as the output will be a very long log of messages.

[link2xt]

lgtm -- i would probably let the python test have some "lp.sec(...)" section titles to allow debugging the test better as the output will be a very long log of messages.

There is no lp fixture in deltachat-rpc-client tests, but INFO messages have a green color easily distinguishable from purple DEBUG messages.