Add increments into STREAMS_AVAILABLE event

[ManickaP]

Description

In case the current count of available streams is bellow 0, STREAMS_AVAILABLE event will indicate 0, making it impossible to know the actual update that came over the wire.

Alternatives

• Report the number from the frame / initial setting directly (MaxStreams value) instead of the increments.
• Use different naming for the properties.

Testing

No existing tests cover the pre-existing values in this event, but this was tested with .NET runtime and System.Net.Quic that plans to take advantage of this feature for it's own stream counting (https://github.com/dotnet/runtime/commit/36210649c502c006e0bdd1439f9ba4c8a976df28)

Documentation

Updated.

cc @MihaZupan @rzikm @CarnaViire @liveans

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.21%. Comparing base (8a741dc) to head (cdce3c6).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #4376 +/- ## ========================================== - Coverage 85.46% 84.21% -1.25% ========================================== Files 56 56 Lines 15426 15429 +3 ========================================== - Hits 13184 12994 -190 - Misses 2242 2435 +193 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ManickaP]

Generally, the change looks fine, but I'd really like to understand more why you want this. How will this help you?

We're exposing a callback similar to STREAMS_AVAILABLE event in System.Net.Quic (https://github.com/dotnet/runtime/issues/101534 - code: https://github.com/dotnet/runtime/blob/f7636f44caa24c1e9613aa417cbbd649d2e37154/src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnectionOptions.cs#L142-L148). The main use is to support opening of new connection when the limit is reached on an existing one. But we also want to know when we can start re-using the original one.

The goal of this change is to report correct numbers, which is not possible due to https://github.com/microsoft/msquic/blob/f5bec530c8ef0824df7294f11d7b3516919899b1/src/core/stream_set.c#L482-L484

I'm also not happy about the uint_16.max cut off for the max value, so I'm starting to get more inclined to expose the raw number from MAX_STREAMS frame in here.