Review requested:

• @nodejs/quic

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

@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 Report

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

@@           Coverage Diff           @@
##             main   #63536   +/-   ##
=======================================
  Coverage   90.32%   90.33%           
=======================================
  Files         730      730           
  Lines      234152   234172   +20     
  Branches    43900    43911   +11     
=======================================
+ Hits       211499   211538   +39     
+ Misses      14374    14367    -7     
+ Partials     8279     8267   -12