fix: Restart i/o when there are new transports in a sync message

[iequidoo]

This currently fails because we don't start I/O for new transports synced from another device.

[Hocuri]

We could restart i/o immediately when receiving a new transport in a sync message, see the commit I just pushed. The future needs boxing and a + Send constraint for it to compile, because this is a recursive call.

Not sure that is the correct thing to do, however; we're in the middle of receiving messages, this is not a good time to cancel and restart i/o. OTOH, changing transports is rare, so, maybe it's fine. A somewhat more "correct" solution would be to somehow put a transports_changed flag on Context, and restart i/o when going IDLE.

cc @link2xt

[iequidoo]

Thanks for fixing! But i think it should be fix:, not feat:.

Not sure that is the correct thing to do, however; we're in the middle of receiving messages, this is not a good time to cancel and restart i/o. OTOH, changing transports is rare, so, maybe it's fine.

I think it's good enough, changing transports is rare indeed, also duplicate sync messages arriving from different transports shouldn't lead to restarting I/O multiple times because modified should be true only once. If it's not the case, that should be fixed as well, though it's minor. I was thinking about adding a one-second sleep, though usually i don't like such solutions.

But note that i really caught this bug when switching to chatmail, so it's not smth that cannot happen to users.

[Hocuri]

@link2xt told me that he's fine with this change

[iequidoo]

The fix here isn't enough however because we don't fetch exisitng messages from the new synced transport, see select_with_uidvalidity() (but it's a known thing). When the second device comes online, there are already messages from our contacts sent only to our new transport (NB: for outgoing messages it's not the case). To fix this properly the first device should probably send uid_next in the Transports sync message so that other devices fetch the same set of messages from a new or readded transport. Not sure it's fine to fetch all messages even if it's a chatmail transport which probably doesn't have infinite number of messages.

If we can't fix this quickly, maybe we need to tell users that they should make sure that their other devices successfully added the new transport, before making it primary.

[Hocuri]

I created an issue for it: #7843