Expose max locally-initiated concurrent_streams

[hackermondev]

This PR adds 2 function to quinn::Connection that expose the maximum number of locally-initiated concurrent streams.

Right now, when this limit is reached Quinn automatically stalls requests to open new streams. In a high-concurrency environment, this can affect performance. By exposing this limit, clients can track their stream count and have the option of starting a new Quinn connection when they reach the limit.

[Ralith]

the option of starting a new Quinn connection when they reach the limit.

Using multiple connections between two peers is, at least in principle, inefficient. This sounds like you're trying to work around an intentional concurrency limit imposed by the peer. If you need more than they advertise, why not ask them to adjust their configuration?

[hackermondev]

why not ask them to adjust their configuration?

For my use case, thats not really an option.

Cloudflare imposes a limit of 100 streams on their http/3 QUIC connections (and http2). This limit is a default hard limit and is not configurable by the site owner. My backend needs to concurrently open many ongoing HTTP requests to origins that may be under Cloudflare and the only way to do that would be to open multiple QUIC connections.

It might be a little inefficient, but its only option.

[Ralith]

I think you'd be better off working with your upstream (incl. Cloudflare) to relax this constraint, but exposing the information seems harmless.

[djc]

Would you mind squashing these commits?