Improve appservice handler to send only the most recent ephemeral events when no stream_id is stored.

[Half-Shot]

Fixes #8743

This changes the AS handler code so that it will appropriately handle new appservices and not hammer the database with large queries. Appservices store their stream_id for read receipts in the database, so they can keep track of how much they need to send in each transaction. However, this value will default to 0 if not found which means the first transaction of read receipts would contain every change made since the creation of the homeserver.

This change aims to make it so that it starts from a reasonable position, which is the last 100 read receipts.

[anoadragon453]

So we've effectively changed the entire focus of this PR. Is starting from stream position 0 no longer a concern?

[Half-Shot]

So we've effectively changed the entire focus of this PR

I don't think so. The PR's focus is to "to send only the most recent ephemeral events when no stream_id is stored". I believe that's what this code does.

Is starting from stream position 0 no longer a concern?

Nope, starting from 0 (or indeed, any position far enough behind the mark) will cause Synapse to fetch the "latest" 100 events rather than all events the appservice has missed.

This is by design, as asking synapse to fetch events from 0, 1, 100, 1000 or whatever when your stream position is at 65535 is going to cause massive latency in both synapse and the bridge while it desperately tries to forward everything recorded. Typically it's not useful to see all read receipts anyway, as appservices are typically only interested in "recent" information.

[anoadragon453]

Nope, starting from 0 (or indeed, any position far enough behind the mark) will cause Synapse to fetch the "latest" 100 events rather than all events the appservice has missed.

Ahhh, didn't twig this would also solve the issue in my last read-through, but of course the DESC makes all the difference. Awesome!

A couple more questions:

• It would still be nice to have a test that checks that only 100 events are returned when having a stream_id gap that's larger than 100, but I won't hold you to it.
• Is this only a problem for read receipts, what about other EDUs?

[Half-Shot]

Is this only a problem for read receipts, what about other EDUs?

Typing is okay because we only ever send the latest events anyway, we don't even store the stream token because appservices aren't interested in "old" typing events (how would that even work).

Presence is okay because we look it up per user, so typically even a stream_id of 0 would mean fetching one presence event.

Read receipts are the outlier because you might well have tons of events come back from a value of 0