KAFKA-20597: Fix prefixScan overflow for prefixes with no upper bound in in-memory state stores

[edenfunf]

Problem

When a prefix has no lexicographically larger successor (e.g. it is all 0xFF bytes), prefixScan computes the exclusive upper bound of its range by incrementing the prefix, which overflows. RocksDBStore already handles this by treating the overflow as an unbounded range, but InMemoryKeyValueStore, MemoryNavigableLRUCache and CachingKeyValueStore called ByteUtils.increment() directly and threw IndexOutOfBoundsException.

Fix

• Centralize the overflow-safe increment as ByteUtils.incrementWithoutOverflow(), which returns null on overflow. The RocksDB code paths that previously defined a private copy now reuse it.
• The three in-memory stores treat a null upper bound as "scan to the end of the keyspace" (tailMap), matching the behaviour RocksDBStore already had.
• ByteUtils.increment() is left unchanged: RocksDBStore.deleteRange() intentionally relies on it throwing, since RocksDB's deleteRange() has no null-upper-bound form.

Testing

• Added prefixScanShouldReturnMatchesWhenPrefixHasNoUpperBound to AbstractKeyValueStoreTest, so it runs against every KeyValueStore implementation. It uses IntegerSerializer's encoding of -1 (0xFFFFFFFF) to reproduce the overflow. Verified the test fails on the unpatched in-memory stores and passes with the fix, while the RocksDB-backed stores pass in both cases.
• Added unit tests for ByteUtils.incrementWithoutOverflow().

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)