RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock

[Daniel Fuchs]

An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.

The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.

This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.

To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

-------------

Depends on: https://git.openjdk.org/jdk/pull/28395

Commit messages:
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372198
  Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430