Use `NtAssociateWaitCompletionPacket` to register wait handle callbacks on Windows.

[teo-tsirpanis]

Since Windows 8, the Windows thread pool has been able to serve an unbounded number of wait callbacks with a single thread, by using the NtAssociateWaitCompletionPacket API to register wait handle completion packets on an I/O completion port. We can make use of this API in the portable thread pool, by leveraging its existing I/O completion port. Other environments like Go and Bun are using it too.

If it's OK to do, should we keep the existing PortableThreadPool.WaitThread mechanism as a fallback if NtAssociateWaitCompletionPacket does not exist? It should exist on all Windows versions currently supported by .NET, barring potential outliers like Xbox.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Should RegisteredWaitHandle always use Win32 TP? #90866

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[jkotas]

If it's OK to do, should we keep the existing PortableThreadPool.WaitThread mechanism as a fallback if NtAssociateWaitCompletionPacket

From OS dependency point of view, it is OK and we do not need to keep the fallback around.

I would be more worried about the validating that it is actually improving performance and not regressing any functionality. Performance related changes in threadpool are tricky. This should wait for .NET 12+.