Define what minimum version of the spec we target

[turt2live]

For things like #22337 and similar the fix is to use the stable endpoint, but at what point do we consider it safe to drop the version check around an HTTP call? In the general case, we drop the version check once "sufficient users" are on a compatible homeserver, however with the spec's new versioning scheme it's hard to determine when that would be exactly.

The spec's new versioning scheme also makes the question a bit awkward, though this will be looked at in #16876

[turt2live]

as an early proposal: I'd like us to target the last 2 spec releases, or roughly 6 months worth of releases. Anything which is older than that and still works is purely coincidence, but also likely to not break, so should be fine.

This is mostly to ensure we're not having to support a server that stopped development in 2003 or something.

[ShadowJonathan]

Coming from #19674; I think it's useful to embed this support into Element code itself, and to enumerate exactly which matrix versions are supported.

Even though matrix versions aren't expected to remove support, it might come in the future with this new versioning system, and it would make Element more robust to check for this explicitly, and to offer a "proceed anyways" dialogue up front.

This could be embedded in js-sdk, which takes the right actions considering what matrix versions the server supports. (If the idea is to switch to rust-sdk, then ruma already has the information necessary to know which endpoints are supported for what matrix version. In fact, it refuses to emit a request object calling the stable URL if it detects the server versions are too old for that.)

[turt2live]

we'd probably tie it into a modernizr-style check, yes.

[t3chguy]

This is even more important now that MSC3244 got ripped out, as the client will crash on servers without room version 9 support.

[turt2live]

js-sdk part landed; now need to figure out how to represent this at the Element layer (and react-sdk?)