[QUIC] Support opening a new QUIC stream on the first connection that has streams available.

[rzikm]

Currently, we use only a single HTTP/3 connection per client (as specified by RFC). However, scenarios like gRPC and server-to-server connections can benefit from using multiple HTTP/3 connections for performance reasons.

We need to design QuicConnection API such that it is possible to open a new stream on the first QuicConnection from the group that has available streams (within peer's advertised limits), or -- if no connection has streams available at the moment -- blocks until some connection does.

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

Issue Details

---

Currently, we use only a single HTTP/3 connection per client (as specified by RFC). However, scenarios like gRPC and server-to-server connections can benefit from using multiple HTTP/3 connections for performance reasons.

We need to design QuicConnection API such that it is possible to open a new stream on the first QuicConnection from the group that has available streams (within peer's advertised limits), or -- if no connection has streams available at the moment -- blocks until some connection does.

Author:	rzikm
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	-

[ManickaP]

This is a requirement for #51775

[ManickaP]

Potential API shape (developed as prototype for #51775 in https://github.com/ManickaP/runtime/tree/quic-stream-open-2):

public sealed partial class QuicConnection : IAsyncDisposable
{
    // New properties: how many streams can the current connection open
    public int AvailableBidirectionalStreamsCount { get { throw null; } }
    public int AvailableUnidirectionalStreamsCount { get { throw null; } }
    
    // New event: fired when the peer sends new stream capacity, gives the recalulated increment, corresponds to receiving MAX_STREAMS frame
    public event QuicConnectionStreamsAvailableEventHandler? StreamsAvailable { add { } remove { } }
    
    // Existing method
    public System.Threading.Tasks.ValueTask<System.Net.Quic.QuicStream> OpenOutboundStreamAsync(System.Net.Quic.QuicStreamType type, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }
    // New overload: failBlocked will immediatelly fail the call if there's no stream capacity (asynchronously, limitations of MsQuic) instead of waiting for the release of capacity from the peer
    public System.Threading.Tasks.ValueTask<System.Net.Quic.QuicStream> OpenOutboundStreamAsync(System.Net.Quic.QuicStreamType type, bool failBlocked, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) { throw null; }
}

// All new types for the StreamsAvailable event
public partial class QuicConnectionStreamsAvailableEventArgs : EventArgs
{
    internal QuicConnectionStreamsAvailableEventArgs() { }
    
    // Contains the difference between new stream limit and current stream limit, i.e. the increment. The actual limits can be retrieved by QuicConnection.AvailableBidirectionalStreamsCount and QuicConnection.AvailableUnidirectionalStreamsCount
    public int BidirectionalStreamsCountIncrement { get { throw null; } }
    public int UnidirectionalStreamsCountIncrement { get { throw null; } }
}
public delegate void QuicConnectionStreamsAvailableEventHandler(object? sender, QuicConnectionStreamsAvailableEventArgs e);

[ManickaP]

Triage: pushing this to future for two reasons:

• the suggested API shape is additive and we don't necessarily need this to remove the preview feature attribute
• the experiments shown it actually makes the perf worse so there's no need to implement this at this moment