Respond with an HTTP 4xx rather than only a `RST_STREAM` to malformed requests

Issue

h2 returns RST_STREAM frames with the PROTOCOL_ERROR bit set as a response to many types of errors in client requests. Many of those cases, when handled by an HTTP/1 server such as the one used in hyper, would result in an HTTP 400 Bad Request response returned to the client rather than a TCP reset (the HTTP/1 equivalent of a RST_STREAM). As a consequence, a client will observe differences in behaviour between HTTP/1 and HTTP/2: a malformed request will result in a 400 response when HTTP/1 is used whereas the same request will result in a reset stream with h2.

Proposal

There was a conversation in the mailing list of the IETF-HTTP-WG about whether a server can send a response to malformed requests instead of treating them as a stream error. From Steffan Eising's last response to that thread:

• Sending a HTTP response is preferable, since this gives much better error reporting on the client side.
• Violations of HTTP/2 framing layer should error on the h2 layer. Basically, the server no longer trusts the client.
• Sending a RESPONSE with subsequent RST is a good pattern

Although there was no consensus about specifying a single correct behaviour, I think it was clear that a 400 response was acceptable.

I could create a PR to make h2 reply a HEADERS+400+END_STREAM frame followed by a RST_STREAM+PROTOCOL_ERROR frame to all the malformed!() macro invocations in https://github.com/hyperium/h2/blob/0077d3dcb4266c18d2b569f0257caff24778335b/src/server.rs#L1506

Start in src/server.rs around line 1506 and inspect the malformed!() macro invocations that handle malformed client requests. Trace each affected path and verify that it emits the proposed HTTP 400 response frames followed by RST_STREAM with PROTOCOL_ERROR, while preserving framing-layer error handling.