Multi-relay routing

[link2xt]

This change adds information about all relay addresses to the public key and sends messages to all addresses listed in the public key contains the list of relays.

Public key is re-generated on the fly to include Direct Key Signature with Notation Data subpacket. Notation name is relays@chatmail.at and the value is a comma-separated list of addresses. We send all relays, but only use the first 3 now. Last seen "From" address is remembered for contacts and is used in the To header, as a fallback when relay list is not in the public key etc., but is not used as the recipient if it is not included in the notation subpacket as well. This will allow us to send from addresses that we don't want to receive messages to in the future if we decide to do so, e.g. send from a classic email server but receive chat messages only on chatmail relays.

There is a known problem that removing a transport does not restart I/O, so you receive messages on the removed transport and it creates ad hoc group as you don't recognize your own address in the To field. Fixing the problem is not for this PR, we probably want to restart i/o and also recognize that the message is a 1:1 message for us just by the intended recipient fingerprint even if there is an unrecognized address in the To field.

Closes #7865

TODO:

• Fix tests/test_multitransport.py::test_download_on_demand. It is currently broken because receiving the same pre-message second time results in trashing the second pre-message and replacing first pre-message, so essentially the message that already existed as a pre-message gets trashed. Then you get problem from Post-message resulted in receive_imf failure #7872 when post-message download is automatically requested, but pre-message got trashed.
• Bring back all the commented out signature subpackets or decide to drop them. SEIPDv2 feature is needed, we also want to recognize it and start sending SEIPDv2 if everyone supports it. Preferred algorithms and hashes practically just increase the signature size at the moment.
• Have some way to update contact public key (aka OpenPGP certificate). Currently (as of 2.44.0) we never update public keys from Autocrypt header. Simple way to fix this is to accept updates, but only from the signed messages and remember the timestamp, so it is impossible to e.g. forge an update with dropped encryption subkey. But we also want to update from Autocrypt-Gossip, this will need more careful merging, e.g. keeping old certificate but replacing user ID with the one that has highest timestamp on the signature. Currently I just trust the updates from Autocrypt header. EDIT: implemented certificate merging
• Merge certificates when vCard is imported as well.
• Per-context lock around prefetching (IMAP loop) or around receive_imf. Currently multitransport tests with download on demand fail because two IMAP loops receive the same messages and download them in parallel and this is not handled properly. EDIT: I have been running this PR for some time and got duplicate message once when sending in a chat that has two my profiles. Duplicate messages have the same Message-ID in message info, so the problem is real even if this happens rarely.
• Have some limit on the number of relays we take from the key, take no more than two or three relays.
• Online Python test that after removing primary relay user can still receive messages. Currently it works already but message is assigned to ad hoc group because the message is not recognized as sent to us. This is supposed to work via "intended recipient fingerprint" (e.g. fix: receive_imf: Look up key contact by intended recipient fingerprint (#7661) #7786) but something does not work. The problem is apparently caused by not stopping IMAP loop when deleting the transport.
• Add relay list of the contact to encryption info if it is in the public key (https://support.delta.chat/t/the-current-profile-in-v2-43-0-no-longer-provides-any-way-to-show-all-relays-design-regression/4873)
• Only update the signature timestamp when actual changes happen to avoid leaking app start time, save the timestamp somewhere in the config (EDIT: using transport timestamp)

[Hocuri]

FTR this PR does not add an "unpublished" flag to a transport. But this can also come in a later PR.

[iequidoo]

The old certificate can expire so this will fail and we should just return the new one if key imprints are the same i guess

[link2xt]

Certificate or the primary key cannot expire by itself, at least in OpenPGP, since V4. Direct key signature (or primary User ID signature if there is no direct key signature) of the primary key or subkey my have "key expiration time" subpacket that tells when the key/subkey expires, we currently ignore it. For encryption subkeys we want to use expiration eventually for forward secrecy, but for this PR i have not looked at encryption subkeys at all. For primary key expiration we will likely have to ignore it, saying that the contact has expired or telling the user that their profile has expired does not make much sense and if we do it now this will break profiles of the users who have in the past imported the keys with 1 year or 5 year expiration time and forgot about it.

Even if we have old certificate with expired primary key and new certificate with renewed primary key, this is just a number from the primary key signature. It does not tell you anything about encryption subkeys. E.g. you may have a contact with an encryption subkey and expired primary key. Someone may gossip you a certificate for this contact with a renewed primary key (newer DKS with extended expiration time) but no encryption subkeys - this does not mean you should now drop all encryption subkeys and accept new certificate without subkeys as a whole without merging.

[Hocuri]

Exciting 🎉!

[r10s]

WOAHHH!11!! what a great stuff! there are already the first copycats: