Streams should be reset when the RequestStream dropped

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.

No files, tests, or entry points are named. Start by tracing RequestStream drop handling and the sender and receiver reset paths, then compare the behavior with RFC 9114 section 4.1.1 and reproduce the reported panic. Done means dropping an incomplete request stream resets or aborts its open directions without a panic.