Send an HTTP/2 RST_STREAM frame when an app completes prior to receiving END_STREAM

[halter73]

This should prevent any stalls on the client caused by not sending stream-level window updates for streams after the app completes.

@Tratcher also suggested starting a timeout when the RST_STREAM frame is sent after which Kestrel would stop tracking the stream. From that point on, the connection would be aborted if any data frames are received for the reset stream.

See #2740

[Tratcher]

Http2Stream.ShoulStopTrackingStream checks RequestProcessingEnded && (EndStreamReceived || Aborted). This is problematic because it could cause us to hold onto resources indefinitely if the client never sends the end-of-stream or reset.

Ending the request processing without consuming the request body is an implicit abort and should trigger a stream reset (after sending end-of-stream) so the client stops sending request data. This also means ShoulStopTrackingStream can go away because it would always be true at the end of the request processing.

Incoming frames for a stream in the closed state can be ignored (except for updating the connection flow control). If we think we're getting too many frames for closed streams we could fault the whole connection, hence the timeout idea above.

[muratg]

This is a good-to-have, but not required for HTTP/2 compat.

We'll look into checking out the client behavior, and how we can actually test this.

[benaadams]

Http2Stream.ShoulStopTrackingStream why don't you like the d?

[Tratcher]

https://tools.ietf.org/html/rfc7540#section-8.1
" An HTTP response is complete after the server sends -- or the client
receives -- a frame with the END_STREAM flag set (including any
CONTINUATION frames needed to complete a header block). A server can
send a complete response prior to the client sending an entire
request if the response does not depend on any portion of the request
that has not been sent and received. When this is true, a server MAY
request that the client abort transmission of a request without error
by sending a RST_STREAM with an error code of NO_ERROR after sending
a complete response (i.e., a frame with the END_STREAM flag).
Clients MUST NOT discard responses as a result of receiving such a
RST_STREAM, though clients can always discard responses at their
discretion for other reasons."