Bookkeeping bug in HttpConnectionPool when handling an HTTP/2 => HTTP/1.1 downgrade

[MihaZupan]

Noticed this one while cleaning up #99364

If we try to downgrade an HTTP/2 connection to HTTP/1.1 and we're already at the connection limit, we'll throw away the new connection.

When doing so, we'll set canUse to false and dispose the stream.

But then we'll still try to construct an HTTP/1.1 stream out of it and eventually handle its failure, which will lead us to decrement the _associatedHttp11ConnectionCount and _pendingHttp11ConnectionCount counters that we never incremented for this connection in the first place, leaving them off by 1.

It looks like we're just missing a return here.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs

Lines 654 to 658 in 4e86b1c

	if (!canUse)
	{
	if (NetEventSource.Log.IsEnabled()) Trace("Discarding downgraded HTTP/1.1 connection because HTTP/1.1 connection limit is exceeded");
	stream.Dispose();
	}

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.