fix(s2n-quic-core): enforce max data limit size for stream and connection

[toidiu]

Resolved issues:

#1675

Description of changes:

Limits::with_data_window accepts a u64 and is a limit specified by our users. In the debug build, we currently enforce that max_data limit is <= u32::MAX with a debug_assert. In the release build, the debug_assert is compiled out and applications can erroneously provide a value larger than u32::MAX.

This PR adds validation to the Limits builder which checks the value is less than u32 and provides a better user error. I also added comments on why its reasonable to restrict the value to u32 in this case. Finally, I convert the debug_asset into an assert to ensure we do no accidentally revert this change and re-introduce the bug only for the release build.

Call-outs:

Note that is issue actually applies to 4 data limits:

• with_data_window
• with_bidirectional_local_data_window, with_bidirectional_remote_data_window, with_unidirectional_data_window

Note that the limits are backed by a IncrementalValueSync which will periodically update a bigger value to the remote endpoint so restricting the initial value to u32 is not a loss of functionality.

Testing:

• Repro the bug: I ran tests against the original code and confirmed that we were getting overflow and UB based on the overflow value.
• I have set the perf runner to use the max value (u32::MAX) as its limit.
• Validated the fix locally
  • by providing values >u32::MAX and getting a ValidationError
  • running perf with a large transfer and confirming a successful run 482s s2n_quic:server:conn: packet_header=OneRtt { number: 28672209 } frame=Stream { id: 0, offset: 40294967189 } ...

Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed? -->

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.