CASSANDRA-21356: Fix same-timestamp tombstone/expiring-cell tie-break…

[arjunashok]

… in cursor compaction

CASSANDRA-21356: Fix same-timestamp tombstone/expiring-cell tie-break in cursor compaction

What's the issue

ReusableLivenessInfo.isExpiring() checked localExpirationTime != NO_EXPIRATION_TIME instead of ttl != NO_TTL. Tombstone cells also set localExpirationTime (stores the deletion timestamp there), so the check returned true for tombstones as well as genuinely expiring cells.

This broke CursorCompactor.resolveRegular()'s logic for picking a winner when two cells have the exact same timestamp. That logic relies on !isExpiring() to tell tombstones apart from expiring cells.
Since both now looked "expiring," it fell back to comparing localExpirationTime directly. Now, the expiring cell's value there is a future timestamp, while the tombstone's is a past one, so the expiring cell always won.

Net effect: an explicitly deleted column could be resurrected by cursor compaction if a same-timestamp write landed in another sstable.

Repro

INSERT INTO t (pk, ck, v) VALUES (0, 0, null) USING TIMESTAMP 100;  -- sstable 1
INSERT INTO t (pk, ck, v) VALUES (0, 0, 'x') USING TIMESTAMP 100 AND TTL 3600;  -- sstable 2
-- major compact -> SELECT v FROM t WHERE pk=0 AND ck=0 incorrectly returns 'x'

Fix

• ReusableLivenessInfo.isExpiring() now checks ttl != NO_TTL, matching AbstractCell.isExpiring().
• CursorCompactor.resolveRegular() checks ttl() == NO_TTL directly instead of relying on isExpiring(), so it's correct even if that method regresses again.

Tests

• ReusableLivenessInfoTest — direct unit coverage of the root-cause check.
• CursorCompactionEquivalenceTest#testSameTimestampTieBreak — end-to-end repro above.

[nitsanw]

Please consider comments

[nitsanw]

The code here is a mirror of Cells.resolveRegular, I think it should be kept as is

[nitsanw]

Good fix, I would add a link to AbstractCell.isExpiring() to the method javadoc, but remove the rest of the comment as it only explains the commit and not the code.

[nitsanw]

Can we not add this test to one of the simple compaction test suites? smaller diff