HttpConnectionPool attempts to create connections for pre-canceled requests #66990
Description
Spinning off from #66673 (comment).
Starting with 6.0, cancelling a request does not remove it from the request queue immediately.
Instead, available connections consume the queue. If they encounter an already canceled request, they simply skip it.
If a connection attempt fails, it will attempt to fail the first request in the queue if the queue hasn't moved since the connection attempt started. If the queue is not empty, it will try to inject a new connection.
This makes it so that each request gets at least one connection attempt.
When injecting a connection, the connection pool only checks that there is a request available, but not whether said request is already canceled. This results in the pool issuing a connection attempt for an already-canceled request.
If there are a lot of cancelled requests in the queue and connection attempts keep failing, the queue will be drained very slowly (we will waste a connection attempt for each entry).
It's possible this will be slower than the rate of incoming requests, resulting in the queue constantly growing with more and more cancelled requests, resulting in an effective memory leak.
This issue is worse for HTTP/2 by default since we only allow a single pending connection attempt at a time, where as we will open Min(requests, MaxConnectionsPerServer) connections for HTTP/1.1 (#66944).