lib: decorate undici classes as platform interfaces

[jazelly]

Node recognizes platform/host objects by counting internal slots.
Undici, as a downstream module, does not have access to internal slots,
and hence its instances are recognized as plain objects. This caused
issues on the structureClone algorithm, which has few restrictions on
non-platform objects.

This PR tries to fix it by decorating Undici classes with the internal
slots so that underlying Serialize() can recognize its instances as
host objects.

On another note, this PR consolidates the lazy loading of Undici, so
that the proxied Undici classes are referential equal.

Fixes: #55120

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.41%. Comparing base (89a2f56) to head (2fffbee).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #55178      +/-   ##
==========================================
+ Coverage   88.39%   88.41%   +0.01%     
==========================================
  Files         652      652              
  Lines      186565   186591      +26     
  Branches    36046    36051       +5     
==========================================
+ Hits       164916   164971      +55     
+ Misses      14908    14896      -12     
+ Partials     6741     6724      -17     

Files with missing lines	Coverage Δ
lib/http.js	100.00% <100.00%> (ø)
lib/internal/util.js	97.67% <100.00%> (+0.82%)	⬆️
lib/internal/wasm_web_api.js	100.00% <100.00%> (ø)

... and 33 files with indirect coverage changes

[mcollina]

I'm a bit at a loss in why we want to keep that symbol private. Wouldn't it benefit everyone to allow a public way to configure this?

On the issue, I think we might be better off in applying this change during the "build"
of undici, so we avoind the performance penalty of Proxy+ReflectConstruct.

[jazelly]

why we want to keep that symbol private

FWIW, we can expose the symbol, but userland can mutate that value and make an object that was supposed to be transferable but now non-transferable, or vice versa. Although this is not unprecedented (think about the concept [[Prototype]] and the accessor __proto__), we made a lot of efforts to make node internal safe because of that.

I am open to suggestions for this one, but I kept it as is in this PR as it looks like from the initial design, and changing that I think is pending a decision.

we might be better off in applying this change during the "build" of undici

This is achievable once the symbol is public accessible.

so we avoid the performance penalty of Proxy+ReflectConstruct

My understanding is the performance penalty is there but not much from this fix, as the module is lazy loaded once only. The benchmark CI should provide more insights.

[legendecas]

I believe undici can use this public API to mark an object as not transferable: https://nodejs.org/api/worker_threads.html#workermarkasuntransferableobject.

A new API can be added to mark an object as not cloneable, like worker.markAsUncloneable(object), along side with https://nodejs.org/api/worker_threads.html#workermarkasuntransferableobject..

[jazelly]

Ah, that will work better. I didn't know that. I think this PR should be closed then.

I can raise a new PR to add that API.