inbound group session update can race with reset backup

[richvdh]

In various places in the codebase, we carry out a read-modify-write operation on existing Inbound Group Sessions. Examples include:

• Marking sessions as backed up or not-backed-up
• Updating the senderdata in response to a /keys/query response (ref Sender Data: Populate missing SenderData when we receive device info via /keys/query #3753)
• Updating the senderdata and the "latest ratchet" when we decrypt a message

Most of these operations should not happen concurrently, since they are all handled from within the application's "sync loop".

However, marking a session as not-backed-up (in particular, when backup is disabled or otherwise reset) can happen out-of-band. In this case, because there is no locking between the operations, it is possible for a write to be lost, leading to sessions not being backed up (potentially causing unable-to-decrypt errors on future devices).

(The converse is not true: marking a session as not-backed-up is treated as an atomic operation by the store implementations, so other updates cannot be lost by a reset-backup operation.)

This would be fixed by the proposed fix to element-hq/element-web#26892, provided we extend it to the sqlite implementation.

[richvdh]

most of these operations should not happen concurrently, since they are all handled from within the application's "sync loop".

In more detail: in theory, an application should not call OlmMachine::receive_sync_changes at the same time as OlmMachine::mark_request_as_sent.

• decrypting a message only happens in receive_sync_changes
• marking as backed up only happens when a backup request completes, via mark_request_as_sent
• handling a keys query response is done in mark_request_as_sent

So the only operation in the list above that can usually race is marking a session as not-backed-up.