Implement Sticky Events MSC4354

[Half-Shot]

Split out from #5017 to allow for easy reviewing. Implements matrix-org/matrix-spec-proposals#4354

As a brief overview of the MSC (though please do at least skim the MSC): This allows any member in a room to mark an event as "sticky" and ensure it gets delivered to other users even in the case of a gappy sync. This is useful for things like RTC where you want call member events to always reach clients, without having to bloat the room with state events that will contribute to overall DAG bloat.

This implementation also deals with ensuring that some events will replace predecessors that share the same "sticky key", and emit the appropriate notices to users of the API.

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[toger5]

This feels super close. I think the only open comment is the sync accumulator prune logic and the delay comment.
Do we have someone from the web reviewers to look at this?

[robintown]

I haven't yet reviewed the file for the RoomStickyEventsStore but hopefully this is a good start:

[robintown]

Still working through this bit by bit as I had some thoughts I wanted to leave on the MSC as well. Here are my comments so far:

[robintown]

Okay, got through the rest, I feel reasonably confident now that everything's doing what it's supposed to.

[robintown]

🎉

[robintown]

Oh, there is one recent change to the MSC: matrix-org/matrix-spec-proposals#4354 (comment)

If a client sends two sticky events in the same millisecond, the 2nd event may be replaced by the 1st if the event ID of the 1st event has a higher lexicographical event ID. To protect against this, clients should ensure that they wait at least 1 millisecond between sending sticky events.

I'm happy to have that wait for a follow-up PR, or simply be an outstanding task for bulletproofing the implementation.

[Half-Shot]

I'm not convinced this should be up to the client but that might be a fight for the spec. Let's see where this leads and follow up with a PR if required. It's certainly fairly edge-cased to me.

Oh, there is one recent change to the MSC: matrix-org/matrix-spec-proposals#4354 (comment)

If a client sends two sticky events in the same millisecond, the 2nd event may be replaced by the 1st if the event ID of the 1st event has a higher lexicographical event ID. To protect against this, clients should ensure that they wait at least 1 millisecond between sending sticky events.

I'm happy to have that wait for a follow-up PR, or simply be an outstanding task for bulletproofing the implementation.