New group consistency algorithm

[link2xt]

TODO:

• Include self address in the To field for compatibility with Delta Chat clients that don't have fix Prepare the receiver for self-sent messages with empty To field #6407
• Update add_timestamp when adding member locally.
• Update remove_timestamp when removing member locally.
• Add some API to list past members. Even if not used by the UIs, it is useful for tests.
• Only allow explicit changes from legacy Delta Chat clients and MUAs
• Generate messages about implicit changes to fix the tests
• Make it possible to leave the group. Currently does not work because need to first remove self locally and then send a message to the group once we have already left.
• Ignore past members after 60 days and make a test for it. EDIT: possibly postpone for another PR as it is not obvious how to avoid users restoring backup from adding members back.

There are some attempts to workaround the case when "member added" (
0a0e715) or "member removed" (1855f84) messages fail to be sent. I am removing them here, going to update add_timestamp or remove_timestamp locally and then do an attempt to send the message out. If the message is not sent because of missing peerstate or because the app is killed, this is the same as having the network lose the message. Especially in the case of removing multiple members by making multiple parallel JSON-RPC or FFI calls it seems better to update the timestamp locally and then send out local state than sending out multiple "member removed" messages which each remove one member but not all the others, not sure if it even worked properly in case the bot or the UI requests multiple member removal in parallel.

Closes #6401

[ell1e]

as it is not obvious how to avoid users restoring backup from adding members back.

Sorry for the uninformed input, I just find algorithm questions interesting. What about a timestamp, where if the backup is older than 24 hours then it might prompt other group members via an automated mail to try to get the updated member list? (This should probably be done in some way to avoid that being done repeatedly when the system time is wrong, however.)

[iequidoo]

Sorry for the uninformed input, I just find algorithm questions interesting. What about a timestamp, where if the backup is older than 24 hours then it might prompt other group members via an automated mail to try to get the updated member list? (This should probably be done in some way to avoid that being done repeatedly when the system time is wrong, however.)

The problem is that in the given algorithm it's not possible to find out whose state for the given membership is actual because timestamps are forgotten after 60 days. We can't store timestamps forever, that wouldn't scale and isn't good for privacy (there should be some time limit after which it shouldn't be known for new members when a particular member was added or removed in the past). As for automated mails in general, currently there are not many such ones, we should avoid them to not reveal the user's network state, whether they restore a backup (as in your question) etc.