ElementR: Ensure Encryption order per room

[BillCarsonFr]

Fixes element-hq/element-web#26684

Encryption order was not ensured with the existing code. So in some case editing an inflight message would encrypt the edit first and schedule it first. That will cause an error because it will send an edit of an unknown event.
It can also invert the message order.

There is a sheduler currently but it doesn't handle encryption, it only queues the event for sending.
The scheduler should probably handle the encryption, but for now I modified RoomEncryptor to ensure order.

Notice that there was already a ordering mechanism but only to ensure order of olmMachine.shareRoomKey but it was not enough.

Added a test to reproduce the problem if the fix is not present.

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• ElementR: Ensure Encryption order per room (#3973). Fixes Element-R: Wrong Message send order (2nd inflight message finally sent first) element-hq/element-web#26684.

[richvdh]

as discussed elsewhere: I don't think this does the right thing

[richvdh]

LGTM mostly. A few suggestions, nits, etc.

[richvdh]

The actual event encryption request will arrive after wait for the prepareForEncryption promise to resolve

I don't really understand this, or what it is trying to say. "The actual event encryption request" == "a call to encryptEvent"? So you're saying that the application will wait for prepareForEncryption to complete before it calls encryptEvent? I don't think that's right.

[BillCarsonFr]

I think it's how it's supposed to work. Legacy is doing the same.
If you starts typing then call encrypt event, we let the prepare finish, then do the encrypt. The share room key part for the secong call should be no op as the room key is already shared

[BillCarsonFr]

Notice that anyhow the olmMachine.shareRoomKey() should be locked per room

[richvdh]

if you starts typing then call encrypt event, we let the prepare finish, then do the encrypt.

but that's not what the comment says?

[richvdh]

... or rather the comment says that we expect the application to wait, and I don't think we do. That's why we have to wait here.

[BillCarsonFr]

I updated the comment:

// If `encryptEvent` is invoked before `prepareForEncryption` has completed, the `encryptEvent` call will wait for
// `prepareForEncryption` to complete before executing.
// The part where `encryptEvent` shares the room key would be no op as it was already performed by prepareForEncryption.
        

[richvdh]

A couple of nits, lgtm otherwise