Improve support for pre-shared sessions (PSK)

[tastypackets]

This would solve...

Simplify Undici for environments that use pre-shared sessions.

The biggest limitation I ran into was pool creating the session automatically. It looks to me like my only option to control the session is pass my own connect function and reimplement most of what's in buildConnector.

undici/lib/dispatcher/pool.js

Line 55 in 250c863

connect = buildConnector({

The implementation should look like...

Some ideas:

• If a session is passed have buildConnector respect / prioritize it, currently it's overwritten. On the surface this seems like the easiest and best option to me, but would like to hear some feedback.
  • Is there a reason we spread these options first instead of last? I'd expect the module should prioritize the passed settings over anything internal by default in most cases.
• Make extending buildConnector easy, for example if this was a class it'd be easy to extend and overwrite just the session method. The new custom connect builder could then be used to pass connect to the pool, so developers don't need to reimplement everything in build connector.
• We could also build something specific for pre-shared sessions, but that feels like a burden on this module and for implementors to learn. I think I'd favor something minimal that keeps the implementor on the hook for connecting in their pre-shared sessions as needed since this is likely the minority of Undici users.

I have also considered...

For now I'll likely pass my own connect function

Additional context

[tastypackets]

I don't mind opening a PR for this, but think it first needs some discussion/review to make sure we are aligned on the path forward.

Also side note I noticed the type for factory options is object, which made this a bit confusing at first when I thought I could simply inject my session on the pool factory only to discover the connect type is actually a function. It'd be great to improve that type.

[mcollina]

Is there a reason we spread these options first instead of last? I'd expect the module should prioritize the passed settings over anything internal by default in most cases.

as you can see, in that example, we are reading the session from the cache. I guess this was added without thinking of the preshared key.

A PR that improves this would be great.

[tastypackets]

@mcollina opened a draft PR to simply spread options at the bottom, so anything can be overriden. Do you think this is okay or was it intentional somethings like socket and ALPNProtocols are set by the module?