Synchronization of transports

[link2xt]

The last commits adds actual transport synchronization, commits before split into PR #7530 are refactorings and preparation.

New TransportsModified event is meant for tests, it is currently emitted when sync message is received and not when the user changes the transports manually as it is already known to the UI.

Transport with ID 1 is never synced except for deletion to avoid ever sending the credentials of the first transport to other email servers. The only downside is that if the password is changed, the user will have to change it on all devices, but this avoids all the discussion of reducing security compared to the current state. The first transport with multi-transport is handled he same way as before without multi-transport.

[iequidoo]

New TransportsModified event is meant for tests, it is currently emitted when sync message is received and not when the user changes the transports manually as it is already known to the UI.

I don't remember where exactly, but it was discussed that for the UI code it's easier to do everything on events rather then to handle also UI-triggered config changes. But if this event is only for tests, that doesn't matter probably.

[iequidoo]

Shouldn't this be max(time(), add_timestamp) so that the deletion "wins" on all devices?

[link2xt]

Added separate commit for easier review, will squash it later: 7d3628e

[adbenitez]

New TransportsModified event is meant for tests, it is currently emitted when sync message is received and not when the user changes the transports manually as it is already known to the UI.

not really, ex. if user has the transports list open to check transport is synchronized, and adds a transport in another device, the list will not be refreshed, user will need to close and open again for the list to refresh, a minor tho

btw, I guess changing/marking the main transport should also be synchronized, is that the case? (sorry for not trying to dive into the rust code to figure out)

[link2xt]

not really, ex. if user has the transports list open to check transport is synchronized, and adds a transport in another device, the list will not be refreshed, user will need to close and open again for the list to refresh, a minor tho

I also think refreshing the list while you are editing it is going to cause more troubles than be useful. I don't expect users to edit transports from two devices simultaneously. Will mark the event clearly as an event that is for testing only.

btw, I guess changing/marking the main transport should also be synchronized, is that the case? (sorry for not trying to dive into the rust code to figure out)

Yes, it is synchronized. Not explicitly, but just when you receive a sync message, the address is changed to the one that sync message comes from. The test checks that this works.