fix: use new QR-contained addresses when alice and bob rejoin with new addresses

[hpk42]

fixes #8329

[link2xt]

Currently when the addresses are known from the public key we only send to these addresses. The idea is that it is possible to send from any address and not receive any messages there as a result, e.g. for "sealed sender".

With this change we now send not only to the addresses from the public key, but to the From address (or even the address from a random QR code that can be modified).

[Hocuri]

LGTM, thanks for fixing!

Note that this will make it slightly harder to introduce sealed-sender: We will need extra logic because otherwise the sender's device will also send to the sealed-sender-address. Should be solvable easily enough by recognizing the sealed-sender address and not sending to it. And of course, the relay can just drop any messages sent to the sealed-sender-address.

I pushed a commit to make sure that the address is actually updated, and the securejoin isn't just skipped because the address is already known. Makes sense to squash-merge then.

[link2xt]

I think better solution is not to update the contact address from the QR code and send to addresses that are not advertised in the key, but to:

1. Send the key request if the QR code has an email address that is not in the public key even if we know the public key, i.e. skip the shortcut if we suspect our relay list is outdated.
2. Modify this code in v3 branch to use the address from the QR code as a recipient here:

   core/src/securejoin/bob.rs

   Lines 314 to 329 in 0a82d73

   	let recipient = contact.get_addr();
   	let alice_fp = invite.fingerprint().hex();
   	let auth = invite.authcode();
   	let shared_secret = format!("securejoin/{alice_fp}/{auth}");
   	let attach_self_pubkey = false;
   	let rendered_message = mimefactory::render_symm_encrypted_securejoin_message(
   	context,
   	"vc-request-pubkey",
   	&rfc724_mid,
   	attach_self_pubkey,
   	auth,
   	&shared_secret,
   	)
   	.await?;
   	let msg_id = message::insert_tombstone(context, &rfc724_mid).await?;

v2 branch can be ignored, it's legacy anyway, as long as it works for v3 securejoin it is good enough.

[Hocuri]

Race condition, both me and link2xt commenting about sealed sender 😂 I didn't see his comment before I posted mine, I'll dismiss my review until we agree on the way forward

link2xt is in favor of a different solution

[hpk42]

sealed sender is unclear how we want to roll it out and so I am not sure how much it counts for fixing the rejoin issue :) We always need to accept messages from relay addresses we don't know, and check the signature to determine who this is.

"contact.addr" feels a bit like a leftover from pre-v2 times. For the standard case of encrypted chatting, it should play no role. contact.addr can already point to a not-signed relay address without this PR, and contact.addr is also used for producing Autocrypt-gossip headers (questionable).

That being said, you both have more overview. I guess i find "contact.addr" semantics sufficiently fuzzy that i am skeptical of adding another address thingie but ok. If threading "contact_addr" through the structs and reverting contact.rs changes feels better to you both, then let's go for that. Not going to try this myself before end of week i guess. Feel free to branch off in a new PR, superseding this one.

[Hocuri]

I'll make a PR that implements link2xt's suggestion, sounds doable quickly, then it's maybe easier to decide