Streams should be reset when the RequestStream dropped

[ealinmen]

See the rfc:

Implementations SHOULD cancel requests by abruptly terminating any directions of a stream
 that are still open. To do so, an implementation resets the sending parts of streams and
 aborts reading on the receiving parts of streams; see [Section 2.4](https://www.rfc-
editor.org/rfc/rfc9000#section-2.4) of [[QUIC-TRANSPORT]
(https://datatracker.ietf.org/doc/html/rfc9000)].

In many cases, The request stream will be dropped directly. For example in reqwest, if total timeout occurs, The entire future that sends the request will be dropped.

We are writing a quic implementation and also using it.

In our implementation, if the application layer drop the stream before the sender or.and receiver sides of the stream are reset or complete, The program will panic directly.

We stand by this. It is no longer possible for the application layer to read and write on the stream, but the stream has not ended. This is unreasonable.

This does bring us a lot of trouble, especially when using the reqwest library. Because h3 does not implement a SHOULD in rfc.

[seanmonstar]

This seems reasonable!