7.0: CompareAndSwapInterface and race condition fixes in atomic operations

[byjg]

Summary

Adds CompareAndSwapInterface — the conditional-write primitive needed to build a correct
distributed lock on top of a cache engine — and fixes three genuine race conditions in the existing
atomic operations.

The races are not theoretical. Forked-process tests reproduce each one against master:

• Twenty concurrent increment() calls on Memcached ended at 8 instead of 20.
• Twenty concurrent add() calls on Redis duplicated the seed value 16 times and dropped appends.
• FileSystem values written with a TTL were already expired when written.

CompareAndSwapInterface

public function setIfAbsent(string $key, mixed $value, DateInterval|int|null $ttl = null): bool;
public function deleteIfEquals(string $key, mixed $value): bool;
public function expireIfEquals(string $key, mixed $value, DateInterval|int|null $ttl): bool;

Implemented by RedisCacheEngine (SET NX EX plus Lua for the guarded operations) and
MemcachedEngine (native add() plus cas()).

Deliberately a separate interface rather than an addition to AtomicOperationInterface, so
nothing that already implements the latter breaks. Callers probe with instanceof and degrade
explicitly.

FileSystemCacheEngine does not implement it. flock() attaches to an inode rather than a path,
and the engine unlinks the file on delete, so two processes can end up holding "the lock" on two
different inodes at the same path. The file system is not a reliable substrate for mutual exclusion
and the engine should not pretend otherwise.

Bug fixes

Memcached — non-atomic seeding in all three atomic operations. increment, decrement and
add initialised a missing key with get() === false then set(). Memcached's own increment()
is atomic, but those two preparatory calls are not:

P1: get() === false          P2: get() === false
P1: set(0)
P1: increment() -> 1
                             P2: set(0)           <- resets the counter
                             P2: increment() -> 1 <- same value issued twice

Now seeded with Memcached::add(), which the server resolves in a single step.

Redis — add() corrupted the list when converting from a plain value. The first add() to a
key written by set() did GET → DEL → re-push → RPUSH unprotected, so concurrent callers each
deleted a list the others were rebuilding. Now a compare-guarded script that only rewrites the key
while it still holds the value that was read.

Redis — TTL applied as a separate command. increment/decrement set the expiry with a
follow-up EXPIRE; a crash in between left a counter with no expiry. Both now run as one script.

FileSystem — expiry dropped outside the lock, and a broken TTL conversion. The .ttl file was
deleted before the lock was taken, leaving the value briefly immortal. The atomic operations also
passed a relative TTL where an absolute timestamp was expected, so increment($key, 1, 60) wrote an
expiry in 1970.

Breaking changes

Area	Before	After
Redis atomic operations	INCR/RPUSH + separate EXPIRE	Lua scripts — requires EVAL to be available
Redis add() TTL	accepted and silently ignored	applied; lists built this way now expire
FileSystem atomic TTL	written as an absolute timestamp	converted with addToNow()

Full detail and migration steps in CHANGELOG-7.0.md.

Testing

• tests/CompareAndSwapTest.php — 18 tests across both engines: expiry, non-owner rejection, and
  the stale-owner-versus-new-owner case.
• tests/ConcurrencyTest.php — forks twenty real processes at a synchronised barrier. Sequential
  tests cannot prove atomicity. Each of these was verified to fail against master before being
  accepted.
• TTL regression test added to tests/CachePSR16Test.php for every engine implementing
  AtomicOperationInterface.

181 tests, 1107 assertions passing. Psalm clean against a clean baseline.

Also included

CHANGELOG-6.0.md, which was sitting untracked in the working tree, committed separately.

[github-advanced-security]

Psalm found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.