Investigate deadlocking virtual threads in low CPU count environments

[alzimmermsft]

Description

This is an investigatory PR into an issue reported when SharedExecutorService uses virtual threads in environments with low platform CPU counts. Where code flows from using SharedExecutorService in one area calling into code also using SharedExecutrorService to asynchronously execute logic (primarily with azure-identity's usage of MSAL4J which heavily uses CompletableFuture<T>).

The change here is leveraging how the JVM pins virtual threads (targeting logic in Java 21, knowing Java 25 made changes where pinning isn't as common) where before CompletableFuture.get() was being used directly, but that uses thread pinning logic. Now, instead that call is wrapped in what looks to be a weird usage of a local ReentrantLock variable where before the call to CompletableFuture.whenComplete the ReentrantLock is locked and the results of whenComplete are ignored, and the only thing done is unlocking the ReentrantLock. After that call the ReentrantLock is attempted to be locked again, when that happens the future is either already complete and the lock is available or the executing thread is pinned in a way where the virtual thread is detatched from the platform thread and pinned. Which should result in virtual threads not deadlocking the platform threads of the system.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.