Correctly handle inputClosed event - #13

Motivation

In HTTP3ToHTTPServerCodec and HTTP3ToHTTPClientCodec, we currently emit a response/request end part if the client/server terminated the stream with an incomplete response/request. This means that downstream handlers can receive a response/request end part before receiving a head/body part.

Per RFC 9114 §4.1, servers should abort the response stream with the H3_INCOMPLETE_REQUEST error code when a client-initiated stream is terminated before receiving enough request parts to provide a full response. Additionally, §4.1.1 describes that clients should not use partial responses.

Modifications

• When we receive the .inputClosed event, HTTP3FrameValidator now checks whether it received a complete request/response, and returns one of three actions: .doNothing (if we received a complete request/response), .notifyDownstream (if we received an incomplete response (clients only)), or .resetStream (if we received an incomplete request (servers only)).
• HTTP3StreamStateMachine now passes that action as an associated value on the inputClosed action.
• HTTP3StreamHandler fires the inputClosed event as before, but for an incomplete message it first fires an HTTP3Error down the pipeline, and for servers, it also sends a QUICResetStreamEvent with the H3_REQUEST_INCOMPLETE code.
• HTTPMessageParsingStateMachine no longer emits an end part when the input closes before a head part arrives.
• Added a peerTerminatedInboundStream case to HTTP3Error.Code.

Result

HTTP3ToHTTPServerCodec and HTTP3ToHTTPClientCodec no longer emit a request/response end part if the stream has terminated without a complete request/response.

Instead, HTTP3StreamHandler handler notifies downstream handlers with an error, and for servers, the stream is also reset.