CASSANDRA-21575: Keep message ids unsigned so they do not inflate every message header

[SEPURI-SAI-KRISHNA]

CASSANDRA-21575

Problem

Message.nextId() draws from a shared AtomicInteger and widens the result to a long:

private static final AtomicInteger nextId = new AtomicInteger(0);

private static long nextId()
{
    long id;
    do
    {
        id = nextId.incrementAndGet();
    }
    while (id == NO_ID);

    return id;
}

Once the counter passes Integer.MAX_VALUE it wraps to Integer.MIN_VALUE, and the negative int
sign-extends into a negative long. Message.Serializer writes the id as an unsigned vint, and a
negative long has all its high bits set, so it always encodes at the maximum width:

id	wire bytes
1	1
2147483647	5
-2147483648 (first wrap)	9
-1	9

That is an extra 4 bytes on the header of every internode message, sustained for the 2³¹ messages
until the counter cycles back through positive, and again on every subsequent wrap. A node sending
50k messages/sec reaches the first wrap in about 12 hours, so this is steady state for any
long-running cluster, not an edge case.

Fix

Mask the counter so ids stay in [0, 2^32). Same number of distinct values, always non-negative,
encoding bounded at 5 bytes. Ids are opaque correlation keys — used only for matching responses to
callbacks in RequestCallbacks — so nothing depends on their sign, and the wire format itself is
unchanged.

Why ForwardingInfo is in the same commit

ForwardingInfo is the FORWARD_TO parameter used for inter-DC write forwarding. It writes ids with
the 64-bit form and sizes them the same way, but reads them back with the 32-bit form:

out.writeUnsignedVInt(ids[i]);              // serialize
size += computeUnsignedVIntSize(ids[i]);    // serializedSize
ids[i] = in.readUnsignedVInt32();           // deserialize  <- mismatch

This is the only 32-bit read of a message id in the tree; everything else uses
readUnsignedVInt/getUnsignedVInt. It is harmless today only by accident — ids always fit in int
because they come from an int counter, so the checkedCast inside readUnsignedVInt32 succeeds
even for sign-extended negative values.

It is therefore a blocker for the fix, not a separate cleanup. Once ids span the full unsigned 32-bit
range this read throws and inter-DC forwarding breaks:

id=2147483648   ForwardingInfo.deserialize: VIntOutOfRangeException
id=4294967295   ForwardingInfo.deserialize: VIntOutOfRangeException

Tests

The existing ForwardingInfoTest only ever used ids 44..49, which is why the width mismatch was
never exercised.

• ForwardingInfoTest.testLargeMessageIdsRoundTrip — round-trips ids across the whole unsigned
  32-bit range including Integer.MAX_VALUE + 1 and 0xFFFFFFFF, for every supported messaging
  version, asserting serializedSize matches the bytes written. Verified to fail without the
  ForwardingInfo change: VIntOutOfRangeException: 2147483648 is out of range for a 32-bit integer.
• MessageTest.testIdsRemainUnsignedAcrossCounterWrap — ids stay non-negative, stay within 32
  unsigned bits, and encode within 5 bytes across the wrap boundary.
• MessageTest.testLargeIdRoundTrips — message headers carrying ids from the upper half of the
  range round-trip for every supported messaging version.

Green locally: ant jar, ant checkstyle checkstyle-test (2907 files), and MessageTest (11),
ForwardingInfoTest (2), MessageSerializationPropertyTest (2), MessageDeliveryTest (4).

Branches

Both defects are present from 4.0 onwards — on 4.0/4.1 the narrowing is spelled
Ints.checkedCast(in.readUnsignedVInt()). This PR targets trunk; happy to prepare backports for
whichever branches you want it on.

Prepared with AI assistance (Claude Opus 5); the commit carries an Assisted-by: trailer.