UTD event was not decrypted after keys were received by the notification client in multiprocess scenarios

[poljar]

This is now split off from #4189.

The issue was that room keys received by the notification client do not trigger redecryption attempts in the timeline.

The OlmMachine has a stream that tells you when a room key has been received, #4189 was fixed by listening to this stream for received room keys and triggering a redecryption attempt, this works since the main client and the notification client share the same OlmMachine in the usual case.

In multiprocess scenarios, the main client and the notificaction client live in different processes and thus can't share the same OlmMachine.

A fix for the multiprocess scenario would involve storing the list of room keys the notification client receives to the database and letting the main client listen to updates to this database.

Bonus points if the solution also persists m.verification.* events the notification client receives in the database, so the main client can consume them instead.

[richvdh]

AIUI, element-hq/element-x-ios#3628 made this work sometimes, but there are cases in which it will not work? Could you help me understand when it will help and when it won't?

[poljar]

Well we theorize that the notification client can receive a room key while the main app is active as well or while it is becoming active but after we can make the explicit "please decrypt" call.

Thus, we think that the workaround is susceptible to a race.