Remove undocumented transaction ID variants of various room endpoints

[tulir]

Fixes #12375

Depends on matrix-org/sytest#1419 and matrix-org/complement#850

Removes:

• POST /rooms/{roomId}/send/{eventType}
• POST /rooms/{roomId}/redact/{eventId}
• PUT /createRoom/{txnId}
• PUT /rooms/{roomId}/forget/{roomId}/{txnId}
• PUT /rooms/{roomId}/join/{txnId}
• PUT /rooms/{roomId}/invite/{txnId}
• PUT /rooms/{roomId}/leave/{txnId}
• PUT /rooms/{roomId}/ban/{txnId}
• PUT /rooms/{roomId}/unban/{txnId}
• PUT /rooms/{roomId}/kick/{txnId}

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file.
• Code style is correct (run the linters)

[reivilibre]

Thanks for bringing this up, this cleanup is very overdue.

Had a quick scour of matrix.org logs and two immediate concerns popping out:

• POST /_matrix/client/r0/rooms/{roomId}/send/m.room.message is being used by lots of people, probably scripts, with generic (or no) user agents
  • Also Mailrise (suggesting that https://github.com/caronc/apprise is using this... seems it is, some of the time — wrote them a message at Matrix: Uses non-compliant POST /_matrix/client/r0/rooms/{roomId}/send/m.room.message caronc/apprise#1550)
  • There may be other identifiable projects using this, I didn't read all the results
• POST /rooms/{roomId}/redact/{eventId} is used by Element iOS :( — opened ticket at Element Classic iOS uses non-standard API for redacting event element-ios#8011 but I guess we probably need to give them some time

Not immediately seeing any other uses of the others, should probably be careful and double-check though.

(also discussed internally)

[tulir]

Yeah the /send one is the most commonly used one, so that should be called out in release notes (perhaps even one or two releases early before the change actually lands?). Most of the endpoints seemed to exist as an unintended side-effect of register_txn_path as they were never specified in any form.

POST /send existed in the first ever spec that was written down: https://spec.matrix.org/historical/legacy/#post-matrix-client-api-v1-rooms-roomid-send-eventtype (but it was removed before the first release in late 2015, it's not present in https://spec.matrix.org/historical/client_server/r0.0.0.html)

[reivilibre]

Happy with this, but we need to make some unfortunate concessions as noted.

Everything else, I'm happy to approve the removal of, after not seeing any usage on m.org.

[reivilibre]

Sad to say, but after discussing with @erikjohnston, we need to preserve /rooms/.../send/... without the txnId on r0 and api/v1 as well.

They've been recently used on m.org and it's going to be hard to just turn these off.

Should comment that although api/v1 is genuine (legacy/historical), r0 was an accidental mistake that is widely used in practice.

I'd be somewhat keen on somehow cracking down on it (e.g. restrict based on user registration date?) but that'd definitely be follow-up PR territory.

[reivilibre]

Sorry to say we need to keep the non-txnId form on r0 only for now, for Element iOS Classic (stopping people from redacting is not a fun bug).

Happy to throw away the other versions though.

We should comment that this is out of spec for ECiOS and link to the ticket element-hq/element-ios#8011

In a follow-up PR I would not be against adding a user-agent check to ensure it's only ECiOS that can use this, to stop anyone else depending on it. (Needs further consideration though, I don't know if this would also backfire on ECiOS forks. Should probably give some grace time for a fix anyway.)