Validate stream receive buffer size

[Gaurav Singh (gaurav2699)]

Description

Reject StreamRecvBufferDefault values that are not powers of two before they reach receive-buffer initialization. This aligns public settings application with persisted-settings validation and prevents the assertion exposed by the randomized settings coverage in #6204.

Failure: https://github.com/microsoft/msquic/actions/runs/33798384900/job/100793494460?pr=6204

Testing

• msquiccoretest.exe --gtest_filter='SettingsTest.StreamRecv*'
• msquictest.exe --gtest_filter='ParameterValidation.ValidateConfigurationParam:ParameterValidation.ValidateConnectionParam'

Added core coverage that verifies invalid input leaves destination settings unchanged, plus public configuration and connection API coverage for invalid and valid buffer sizes.

Documentation

No documentation impact.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.08%. Comparing base (ceba4ec) to head (5a9e0a9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6302      +/-   ##
==========================================
- Coverage   85.96%   85.08%   -0.89%     
==========================================
  Files          60       60              
  Lines       18976    18976              
==========================================
- Hits        16313    16145     -168     
- Misses       2663     2831     +168     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Guillaume Hetier (guhetier)]

This changes which values the API accepts.
Was it documented only power of two are accepted? Is the requirement for power of two a consequence of a recent fix on the buffer growth logic or was it there before?

We need to be careful this won't regress a functioning scenario for apps.

[Gaurav Singh (gaurav2699)]

This changes which values the API accepts. Was it documented only power of two are accepted? Is the requirement for power of two a consequence of a recent fix on the buffer growth logic or was it there before?

We need to be careful this won't regress a functioning scenario for apps.

Yes, the power-of-two assertion has existed internally since the original receive-buffer implementation, but the requirement was never documented for  StreamRecvBufferDefault . The public settings path has accepted all values >=4096 since 2020, while registry loading separately enforced power-of-two values.
This was exposed because #6204 started randomizing the previously-disabled settings. I agree rejecting previously accepted API values could regress applications. Debug builds assert these values and release builds accept them. We should in that case remove the debug assert?