Lazy threadpool initialization

[rzikm]

Describe the feature you'd like supported

In .NET Runtime, there is some logic conditioned on QUIC support on the platform (related to HTTP3). When checking QUIC support, we load the MsQuic library into the process and check the version (and query the TLS backend type), if compatible, we set some global flag.

However, calling MsQuicOpenVersion causes some threads to be created, which increases overall resources used by .NET programs even if they end up not using QUIC at all.

Proposed solution

Initialize the threadpool(s) lazily once the first Connection or Listener is created.

Additional context

We have resorted to a temporary workaround of calling MsQuicClose and later lazily reopening the library when necessary.

[nibanks]

#3034 is already doing this, but you need to make sure not to create registrations if you don't want threads to get created. That is the "lazy" signal that you're about to do work and need threads.

[nibanks]

@rzikm this is fixed with recent PRs, but it is delayed to registration creation. Not connection/listener. Please update .NET to consume it and validate that querying MsQuic support no longer creates threads.