Add room_types/not_room_types filtering to Sliding Sync /sync

[MadLittleMods]

Add room_types/not_room_types filtering to Sliding Sync /sync

Based on MSC3575: Sliding Sync

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct
  (run the linters)

[MadLittleMods]

This doesn't affect this PR because we're just looking at the create event which we will always have but I'm curious about this for get_state_at(...) in general.

For state in a room, do we have to worry about gaps? What happens if we try to get state a point in the room we haven't backfilled before?

I guess I just don't know if we have all historical state in the room. I know we have the whole auth chain of things which will be a subset of state 🤔

[MadLittleMods]

@erikjohnston Is this a legit concern?

[MadLittleMods]

Talked with @erikjohnston and got some knowledge.

In general, asking for state at a random position is dubious and we should careful about our usages.

It's not a problem in our current Sliding Sync usages because we're using it with the to_token which is at the front of the room so there will always be some latest event before the to_token to get state at that positon.

[MadLittleMods]

Thanks for the review @erikjohnston 🦅