quic: add listEndpoints API

[jasnell]

Adds the listEndpoints API. Since we're maintaining a registry of endpoints to be re-used with connect, this helps enumerate which endpoints are currently available.

Also apply a few other minor cleanups

@nodejs/quic

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[nodejs-github-bot]

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

[jasnell]

@nodejs/quic @mcollina ... there is an API design question in this... right now, the module maintains a global set of QuicEndpoint instances for re-use. When calling connect(), it will, by default, use an existing QuicEndpoint if one is available. The selection is pretty unsophisticated (use the first active one in the list). Should we introduce a pluggable QuicAgent mechanism that allows users to customize the selection process? The default QuicAgent would use the current behavior, but the user could potentially have something like const agent = new MyQuicAgent(); const session = connect(..., { agent }) to provide their own re-use strategy. I went with the simple global agent for now.

The module-level listEndpoints API makes sense for that, but if we end up wanting a QuicAgent type of mechanism then we should do that now.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.37%. Comparing base (df09b2a) to head (b6bde18).
⚠️ Report is 82 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #63536 +/- ##
==========================================
+ Coverage 90.32% 90.37% +0.05% 
==========================================
Files 730 730 Lines 234152 234521 +369 Branches 43900 44141 +241 ==========================================
+ Hits 211499 211954 +455 + Misses 14374 14328 -46 + Partials 8279 8239 -40 

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

... and 39 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.

[martenrichter]

Please look at the discussion at:
https://www.w3.org/wiki/WebTransport/Meetings2023#WebTransport_Bi-weekly_Virtual_Meeting_#125_-_May_19_2026 (see part beginning with "Pooled stats counters persist across session boundaries #762" )
There are some privacy concerns on sharing webtransport sessions. Probably not relevant for node.js more for the UA.
But certainly related to this new api. But there are other related discussions.

[mcollina]

lgtm

[mcollina]

Overall yes, we should add an Agent system to make the reuse constrained and limited if someone needs that.

[jasnell]

If we're going to add an agent, then I think this PR needs to take a different approach. Moving to draft for now.

[jasnell]

Actually.. thinking about it more... a QuicAgent type of thing doesn't actually make sense :-) ... the QuicEndpoint already acts like an agent... user code can figure out whatever approach it wants to re-using them.

Specifically:

When connect(...) is called, it will create a QuicEndpoint automatically if one does not exist. Or, you can call new QuicEndpoint(...) to create one and pass it in with the connect(...) to use it. Or, you can use the endpoint directly to connect. The point being, it ends up largely serving the same role as the Agent in http 1 and 2.

[nodejs-github-bot]

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

[metcoder95]

+1 on the Agent mechanism

[jasnell]

Landed in 0fe48b6