Fix client v2 varint overflow

[romka]

Summary

Fixes BinaryStreamReader.readVarInt in client-v2 so malformed or overflowing varints are rejected instead of being decoded into corrupted or negative int values.

The previous implementation accumulated into an int while looping up to 10 bytes. For bytes after the 5th, Java masks int shift distances modulo 32, so overlong varints could corrupt lower bits. It also allowed 5-byte values above Integer.MAX_VALUE, which can become negative sizes/counts.

This PR covers one of the cases described in the issue #2902.

Changes

• Limit readVarInt decoding to 5 bytes.
• Reject fifth-byte payloads that exceed non-negative int range or continue past 5 bytes.
• Add focused tests for:
  • Integer.MAX_VALUE
  • overflow above Integer.MAX_VALUE
  • overlong varint encoding

Compatibility

This changes handling of malformed/overflowing binary varints from silent decoding to IOException. Valid non-negative int varints are unchanged.

Testing

• mvn -Duser.timezone=UTC -pl client-v2 -am -Dtest=BinaryStreamReaderTests -Dsurefire.failIfNoSpecifiedTests=false test
• mvn -Duser.timezone=UTC -DskipITs clean verify

Checklist

• Unit tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG

[github-actions]

Repository collaborators can run the JMH benchmark suite against this PR by commenting:

/benchmark

Optional regression threshold override (Δ% on Time or Alloc/op; defaults to 10%):

/benchmark threshold=15

Only one benchmark run per PR is active at a time — issuing a new /benchmark comment cancels the previous run. After the run finishes a separate comment will be posted comparing it against the latest scheduled run on main; the PR check fails if any benchmark regresses by more than the threshold.

[CLAassistant]

All committers have signed the CLA.

[chernser]

@romka

Thank you for the contribution! We will review the PR.
Please create an issue so this PR is not orphan.

Thanks!

[chernser]

what var int could be in data from server?
problem may be we need to adjust using 64-bit varint.

[romka]

Please find more details in the issue: #2902.

The tests in this PR demonstrate two cases that are currently decoded incorrectly:

• Overflow: 80 80 80 80 08,
• Overlong encoding: 80 80 80 80 80 01.

I agree that if any of these readers are expected to decode protocol-level 64-bit varints, then introducing a dedicated long-returning reader (and updating the relevant call sites) would be a better long-term solution. My goal in this PR was to make the current int-returning implementation fail explicitly instead of silently returning a corrupted value.