Support Matrix 1.3

[clokep]

We should finish up implementation of Matrix 1.3, the first thing to do is to make a checklist of remaining tasks from the release notes (https://matrix.org/blog/2022/06/16/matrix-v-1-3-release#the-full-changelog):

---

Client-Server API

• Deprecate the sender_key and device_id on m.megolm.v1.aes-sha2 events, and the sender_key on m.room_key_request to-device messages, as per MSC3700.
• Make from optional on GET /_matrix/client/v3/messages to allow requesting events from the start or end of the room history, as per MSC3567.
• Add refresh tokens, per MSC2918. MSC2918 Refresh tokens implementation #9450
• Describe a structured system for event relationships, as per MSC2674.
• Describe how relationships between events can be "aggregated", as per MSC2675 and MSC3666.

Server-Server API

• Add a destination property to the Authorization header, as per MSC3383. Implement MSC3383: include destination in X-Matrix auth header #11398

Application Service API

• Add timestamp massaging as per MSC3316. Add query parameter ts to allow appservices set the origin_server_ts for state events #11866

Room Versions

• Add room version 10 as per MSC3604. Add support for room version 10 #13220
• Update the default room version to 9 as per MSC3589. Bump the default room version to 9 per MSC3589. #12058

---

Other remaining things from above:

• /relations returns an extra original_event field: Synapse returns unspecced property original_event from /relations #12930
  • See Do not return unspecced original_event field when using the stable /relations endpoint #14025.
• Refresh tokens can be disabled currently.

[clokep]

I'm unsure if MSC3700 has anything for the server to do or not, but I found some of those keys by grepping the source.

[clokep]

• Deprecate the sender_key and device_id on m.megolm.v1.aes-sha2 events, and the sender_key on m.room_key_request to-device messages, as per MSC3700

From a conversation in #synapse-dev it seems like there is nothing to do for MSC3700, @erikjohnston's summary:

Yeah, [the sender_key and device_id] are only used as a dirty "oh look we don't know about that device and it should be cached whoops lets go and invalidate our cache"

[clokep]

Refresh tokens can be disabled currently.

I believe this is fine since the spec says:

Handling of clients that do not support refresh tokens is up to the homeserver; clients indicate their support for refresh tokens by including a refresh_token: true property in the request body of the /login and /register endpoints. For example, homeservers may allow the use of non-expiring access tokens, or may expire access tokens anyways and rely on soft logout behaviour on clients that don’t support refreshing.