Remove spurious event_id from federation APIs, and convert to POST?

Nobody has claimed this yet.

The following federation APIs have `roomId`s and `eventId`s in the path which are completely redundant:

* `PUT /_matrix/federation/vN/send_join/{roomId}/{eventId}`
* `PUT /_matrix/federation/vN/invite/{roomId}/{eventId}`
* `PUT /_matrix/federation/vN/send_leave/{roomId}/{eventId}`
* `PUT /_matrix/federation/v1/exchange_third_party_invite/{roomId}`

The `room_id` is given in the body, and the `event_id` is either in the body or calculated from the hash. Deduplication takes place based on that event id, not on the path params.

The implication of all this is that we could remove the `roomId` and `eventId` path params, and convert the request to a POST.

One counter-argument is that it would make sharding by room harder if the `roomId` was omitted. So maybe we should leave that there (but still remove `eventId` and switch to POST).

While I'm here: why is [`PUT /_matrix/federation/v1/3pid/onbind`](https://matrix.org/docs/spec/server_server/r0.1.3#put-matrix-federation-v1-3pid-onbind) a `PUT` ?

Review the listed federation API endpoints and the linked Matrix server-server specification, comparing the path parameters with the request bodies and deduplication behavior described here. Resolve whether roomId should remain for sharding, whether the methods should become POST, and why 3pid/onbind uses PUT; done means the API decision and affected specification changes are agreed.

Written by the indexing model from the issue text.