Wrong status code for 'invalid request payload' errors?

The specification suggests in various places to use the `400` status code for invalid request payloads, eg. the `M_UNKNOWN` error for a bad login type on the login route, or the `M_MISSING_PARAM` error on the `/pushers/set` route.

The more appropriate status code here would probably be `422` instead:

> The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

([source](https://tools.ietf.org/html/rfc4918#section-11.2))

[This part](https://matrix.org/docs/spec/client_server/r0.4.0.html#api-standards) of the specification claims that...

> Errors are generally best expressed by their error code rather than the HTTP status code returned. When encountering the error code M_UNKNOWN, clients should prefer the HTTP status code as a more reliable reference for what the issue was.
>
> For example, if the client receives an error code of M_NOT_FOUND but the request gave a 400 Bad Request status code, the client should treat the error as if the resource was not found. However, if the client were to receive an error code of M_UNKNOWN with a 400 Bad Request, the client should assume that the request being made was invalid.

... which means that in this case, *some* of the currently-`400` errors could *theoretically* be safely represented as `422`s (namely, those with an error code other than `M_UNKNOWN`), but all of the `M_UNKNOWN` errors - like that in the login route - could not be.

However, with the current ambiguity in the specification on whether the HTTP status codes are normative or non-normative, there's a good chance that some clients are relying on these sort of errors having a `400` status code either way, `M_UNKNOWN` or not. Which means that this seems like it would need a specification change to resolve, unless there's some sort of existing guidance on this that I'm not aware of.

Start with the API standards section linked in the issue, then compare its status-code guidance with the login route's M_UNKNOWN example and the /pushers/set M_MISSING_PARAM example. Done means the specification's treatment of these invalid-payload responses is resolved and documented consistently.

Written by the indexing model from the issue text.