Passing timestamp to clients

[kegsay]

Every room has a timestamp associated with it, which is the origin_server_ts value of the most recent event in the timeline. However, not all events are "useful". We added bump_event_types to only move rooms up the list if the event type matched one provided by the client. E.g bump_event_types: [ "m.room.message", "m.reaction" ] would only look at the timestamps for those event types when determining sort order. This means the most recent event isn't always taken into account, which is good because we don't want things like display name changes to bump rooms up the list.

This is encapsulated in a map[event_type]timestamp per room. This information is treated as global and is represented in RoomMetadata here https://github.com/matrix-org/sliding-sync/blob/main/internal/roomname.go#L42

However some of these events may be old, from before you have joined. Therefore, we need to track timestamps on a per connection basis. This is keyed by listKey (as bump_event_type is per-list) here https://github.com/matrix-org/sliding-sync/blob/main/sync3/room.go#L38 which is updated when live events come in and call SetRoom - https://github.com/matrix-org/sliding-sync/blob/main/sync3/lists.go#L95 and https://github.com/matrix-org/sliding-sync/blob/main/sync3/handler/connstate_live.go#L293 . This map is loaded when the connection is initially made here https://github.com/matrix-org/sliding-sync/blob/main/sync3/handler/connstate.go#L125

The point of this issue is to make timestamp key in the sync3.Room response which is set to the correct timestamp which is what the server is using to sort based on. This needs to union multiple timestamps because 1 room can be in 2 lists each with different bump_event_types (e.g one bumps on messages, the other room names, so 2 different timestamps). In this case, choose the highest value.

End-to-end tests should ensure that:

• upon joining a room, you don't see timestamps from before your join event (the join event is the lowest timestamp that should appear to avoid leaking information).
• Events which shouldn't bump do not alter the timestamp.
• Events which should bump do alter the timestamp.
• Multiple lists with different bump_event_types choose the highest value for the timestamp.

[kegsay]

This landed!