feat: introduce keyupdate message to inform contacts about relay changes

[hpk42]

Introduces keyupdate messages: when the published relay list changes, a symmetrically encrypted message carries the re-signed key to non-blocked key-contacts from accepted chats.

Wire format, audience and sending policy: src/keyupdate.rs module docs.

For full background and motivation, see https://github.com/chatmail/core/blob/hpk/draft-keyupdates/draft/keyupdate-draft.md as discussed in #8595.

You can use the following SQL statement to check the number of contacts versus keyupdate recipients as selected by this PR:

SELECT
  (SELECT COUNT(*) FROM contacts WHERE id>9) AS contacts,
  (SELECT COUNT(*) FROM contacts c
   WHERE c.id>9 AND c.fingerprint<>'' AND c.blocked=0
     AND EXISTS (SELECT 1 FROM chats_contacts cc
                 INNER JOIN chats ch ON ch.id=cc.chat_id
                 WHERE cc.contact_id=c.id
                   AND cc.add_timestamp >= cc.remove_timestamp
                   AND ch.id>9
                   AND ch.type IN (100, 120, 165) -- Single, Group, InBroadcast
                   AND ch.blocked=0)
  ) AS keyupdate_recipients;

For some profiles I have access to, some real-world data on keyupdate recipient sizes:

profile age	contacts	keyupdate recipients
~8 years	~7000	~2000
~3 years	~1700	~700
<1 year	~1100	~500
<1 year	several small test profiles	<20 each

Even for the oldest profile, reaching ~2000 key contacts can re-establish chat connectivity that is currently broken (the "mutual silence" case), so it's not clear that constraining the recipient set further would be worth the loss. Most likely there will be a lot of failure DSNs that we currently don't do much with, but that's arguably a general problem for all other chat messages, too.

Known problem: old contacts who uninstalled Delta Chat but still read the mailbox with another client

Key-contacts who once used Delta Chat on a classic email provider and later uninstalled might receive keyupdates as undecryptable mail in a mailbox they still read (given the keyupdate passes the spam filter). They have no way to opt out, and we get no signal either, because their provider may accept the mail, without failure DSNs. With relay changes currently being rare manual acts, this probably stays below the noise that group messages or other randomly arriving spam can already cause for such contacts. But it might become a real annoyance with frequent relay changes: automatic relay management should be careful to ship without rate-limiting keyupdates in some way. Note, however, that this whole problem usually only exists for old profiles, and then only for their contacts who uninstalled Delta Chat and continue to use the mailbox with another client, so we should be careful not to optimize for this particular case at the expense of helping "mutually silent" contacts, or peers with otherwise de-synchronized relay knowledge about each other, to re-establish chat connectivity so message sending will succeed afterwards.