feat: let clients receive events they missed while they werent connected

Currently, clients can't receive events they missed, when they weren't connected to the server. This can happen for many reasons, but most notably because the user closed the client application, or because of an internet failure. This means that once they reconnect, their state will be out-of-date, and they will need to refetch all of the data instead of incrementally fetching what they need. This issue is for tracking potential solutions.

Solutions?

solution 1

1. introduce a new StreamEventsResponse.event variant:

   message StreamId {
   	uint64 stream_id = 1;
   }
   

2. StreamId lets the client know the ID of the current stream they are using. This will be sent to the client upon connection of the stream.
3. introduce a new StreamEventsRequest.request variant:

   message KeepTrack { }
   

4. KeepTrack lets the server know that after the current stream has ended, it should store any events dispatched to this user under the ID of the stream that ended.
5. introduce a new RPC to ChatService called SynchronizeEvents. it's request type will take a uint64 stream_id = 1;.
6. ChatService.SynchronizeEvents will return a list of events, ordered from oldest to newest, that the client has missed since the end of the stream the ID was bound to. After this is called, the stream ID should be invalidated, and all the events should be removed.

The events should only contain the newest state, and nothing in between. New messages should not be kept, only edited / deleted messages, as new messages will potentially take up a lot of storage. The client can fetch the new messages itself.

solution 2

1. servers attach a "last modification time" to basically everything (profiles, messages, guilds, channels, etc)
2. clients later can synchronize their state by sending a request with the last time they were connected. the server will figure out what's missing and send it to the client. the response can simply be a list of events, ordered from oldest to newest that the client can apply easily without writing new logic.

Unlike the first one, this doesn't require much protocol change aside from one new RPC, and doesn't require the server to store redundant state. However this is potentially much more complex for servers (?).

Beginnen Sie mit der Überprüfung der in diesem Issue beschriebenen Varianten von StreamEventsRequest und StreamEventsResponse sowie der Einstiegspunkte von ChatService. Vergleichen Sie die vorgeschlagenen Ansätze mit stream-ID und last-modification-time und bestimmen Sie anschließend, welcher Synchronisationsvertrag ausgewählt wird. Als abgeschlossen gilt die Arbeit, wenn ein abgestimmtes Protokolldesign für verpasste Ereignisse vorliegt, einschließlich Aufbewahrung, Reihenfolge, Invalidierung und Synchronisationsverhalten.