quic: do not destroy incoming streams that have a consumer

[trivenay]

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

• an onstream callback (any negotiated protocol), or
• session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

• Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
• The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
• This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
• The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65335      +/-   ##
==========================================
+ Coverage   90.10%   90.12%   +0.02%     
==========================================
  Files         752      752              
  Lines      252207   252250      +43     
  Branches    47446    47444       -2     
==========================================
+ Hits       227254   227346      +92     
+ Misses      16261    16206      -55     
- Partials     8692     8698       +6     

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	100.00% <100.00%> (ø)
lib/internal/quic/state.js	100.00% <100.00%> (ø)

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

[trivikr]

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

[trivenay]

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

[nodejs-github-bot]

Landed in fd5b135