Range compaction

[stevefan1999-personal]

Description

This Pull Request adds range compaction and shrinking functionality to optimize memory usage in the QUIC range management system. The key changes include:

• New Functions:

  • QuicRangeCompact: Merges overlapping or adjacent subranges to reduce fragmentation and improve search performance.
  • QuicRangeShrink: Dynamically reduces the allocation size of the subranges array when usage is significantly below allocated capacity.
  • QuicRangeCalculateShrinkLength: Helper function to determine optimal shrink thresholds based on configurable parameters.

• Integration: Modified existing range operations (QuicRangeAddRange, QuicRangeRemoveRange, QuicRangeSetMin, QuicRangeRemoveSubranges) to automatically compact ranges after modifications that could create adjacent subranges.

These optimizations are particularly beneficial for long-running, highly fragmented QUIC connections where range operations accumulate over time, helping to maintain efficient memory usage and performance.

Remediates the problem in #5450, but still does not prevent worst case mentioned.

Testing

Existing unit tests for range operations (in src/test/) should continue to pass and provide coverage for basic functionality. Additional tests are recommended for:

• Compaction logic with various overlap scenarios
• Shrink behavior at different usage thresholds
• Edge cases like single subrange compaction and allocation failure handling

Documentation

No user-facing documentation impact, as these are internal implementation optimizations. If any public APIs are indirectly affected, ensure API documentation remains accurate.

[csujedihy]

Remediates the problem in #5450, but still does not prevent worst case mentioned.

Just to be clear, "Pathological sequences like alternating high/low packet numbers cause O(n) insertion costs due to array shifting." is the worst case you were referring to, right?

Looks like we need a better data structure to handle ranges in the future, like a RB tree, which we did in Windows TCP.

[codecov]

Codecov Report

❌ Patch coverage is 52.08333% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.96%. Comparing base (1a1ef81) to head (1f75532).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/core/range.c	52.08%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5451      +/-   ##
==========================================
- Coverage   84.61%   83.96%   -0.66%     
==========================================
  Files          59       59              
  Lines       18600    18635      +35     
==========================================
- Hits        15738    15646      -92     
- Misses       2862     2989     +127     

☔ View full report in Codecov by Sentry.
📢 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.

[stevefan1999-personal]

Remediates the problem in #5450, but still does not prevent worst case mentioned.

Just to be clear, "Pathological sequences like alternating high/low packet numbers cause O(n) insertion costs due to array shifting." is the worst case you were referring to, right?

Looks like we need a better data structure to handle ranges in the future, like a RB tree, which we did in Windows TCP.

Correct. Incidentally I'm writing a first boot memory allocator in kernel context, and I need to solve the memblock problem and face a similar problem, then I used a Scapegoat Tree to act as a BTreeMap and hacked out an easier to understand memblock :)

This is eeriely similar to the range data structure here, though