fix(stream): avoid RST before initial HEADERS on idle streams

[DDtKey]

Description

If a request body errored before the opening HEADERS were flushed, h2 clears the pending frames and send RST_STREAM first. That leads to a reset on an idle stream, which HTTP/2 forbids, leading peers to reply with PROTOCOL_ERROR/GOAWAY.

But, more importantly, that PROTOCOL_ERROR response closes the TCP connection (as a connection error per RFC 7540 5.4.1), disrupting other in‑flight streams and potentially leading to a reconnect loop.

Expectations

• RFC 7540 5.1: only HEADERS / PRIORITY are valid on idle streams.
  https://datatracker.ietf.org/doc/html/rfc7540#section-5.1

Receiving any frame other than HEADERS or PRIORITY on a stream in this state MUST be treated as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

• RFC 7540 6.4: “RST_STREAM frames MUST NOT be sent for a stream in the ‘idle’ state… PROTOCOL_ERROR.”
  https://datatracker.ietf.org/doc/html/rfc7540#section-6.4

RST_STREAM frames MUST NOT be sent for a stream in the "idle" state.
If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

After fix

When the stream is still pending open, h2 now keeps the queued HEADERS and enqueues the RST_STREAM after them.
This prevents idle-stream resets and keeps behavior within the spec. Already-open streams keep the previous reset behavior.

[DDtKey]

@seanmonstar may I kindly ask you to review?

Tbh, tracking this issue wasn’t easy, but it’s definitely possible to encounter in specific setups where Body streams may experience rapid errors.

[seanmonstar]

Great fix, thanks so much!