quic: Should QuicStream be destroyed, if onstream is not set

[martenrichter]

Currently, incoming streams are destroyed, if the onstream callback is not set.
This sounds at first sight logically, however one can also use for http/3 onHeaders callback, later with webtransport support, it would be also onsessionid which is called for a webtransport data stream.
Then for http/3 onstream is most times pretty useless, as the other callbacks, which are opposed to the current docu are called later than onstream for h3 are more useful. So I have actually only stubs in onstream.

This is related to @pimterry api redesign (@jasnell may be also interested).

[pimterry]

Agreed - if we're exposing the stream via other APIs, it shouldn't mysteriously die if it's being used elsewhere. The invariant should be broader: if we get a stream, and it's not exposed at all (nothing listening to any relevant callback) then it should be cleaned up automatically so it's not left hanging. It's not really about the onstream callback specifically.

[trivenay]

Opened #65335 implementing the invariant discussed here — an incoming stream is destroyed only when the session has no consumer at all for it: no onstream, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported state). Stub onstream handlers are no longer needed to keep h3/WebTransport streams alive.

Please take a look when you get a chance.

[trivenay]

One related observation as a possible follow-up: per RFC 9114 §4.1.1, rejecting a request stream without processing it should signal H3_REQUEST_REJECTED so the client knows it is safe to retry. The destroy path currently sends the generic error code instead. If that sounds right, happy to pick it up as a small follow-up.