quic: start adding in the internal quic js api

[jasnell]

While the external API for QUIC is expected to be the WebTransport API primarily, this provides the
internal API for QUIC that aligns with the native C++ QUIC components. This is the first of several PRs that will fill out this part of the implementation. The goal of doing this incrementally is to make things easier to review by doing it in smaller chunks

[mcollina]

Unless a massive improvement is planned on WebStream, I would recommend not using them in this lower level. They are 1 order of magnitude slower than Node streams. Using them here would limit the applicability of our Quic implementation.

Just using functions and callbacks might even be faster.

[splitice]

Really interesting @jasnell .

Just a reminder we have continued to apply fixes to your original attempt many of which probably still apply today (latest branch: https://github.com/HalleyAssist/node/commits/test_quic16/ - not everything in this branch is relevant). Some fixes could probably done better with more drastic changes, however they all represent observed leaks, infinite loops or crashes observed in our staging and pilot environments.

Including yesterday a fix for blocking streams creating an infinite loop in SendPendingData (which can be tested for with rx packet loss simulation). When you do get a JS api I'll try and contribute some of these directly.

[Qard]

Makes me a bit nervous that these names are a single character apart. High chance of typos in future maintenance.

[jasnell]

Not ignoring this comment, just plan to address it in a subsequent iteration

[jasnell]

Updated the implementation fairly significantly here.

1. Endpoint,Session, and Stream are no longer EventTarget subclasses. Instead, the constructor for Endpoint takes an object will callbacks that will be called. This preserves the idea that these are low-level APIs meant to be wrapped by other APIs to expose to users. The fact that these aren't EventTargets and Event objects aren't used should yield a fairly significant performance boost in the underlying bits.
2. The constructors can be called directly. Since these are meant to be internal APIs there's not much harm in exposing those
3. Uses more primordials consistently. I know there's some effort to remove primordials but as an internal API it makes sense here.
4. Removing the use of ReadableStream/WritableStream at this level. These will be replaced with lower-level APIs and callbacks in the next step.

[nodejs-github-bot]

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

[jasnell]

This is generally ready to go except for the "Coverage" github CI tests. Working on increasing the test coverage now to the minimum that'll pass.

[mcollina]

I would recommend we call this QuicInternalStream, otherwise this will quickly get confusing

[mcollina]

The copy here would be problematic for perf reasons. Is this necessary?

[jasnell]

This will likely be changed to detach the underlying ArrayBuffer instead of copy. The issue is that we do not want the buffer to be mutated while it is pending to be sent.

[mcollina]

Maybe add a TODO so we don't forget?