Fix ZREMRANGEBYRANK missing reply and unnormalized negative ranks - #2028

Symptom

ZREMRANGEBYRANK mishandles every rank range that Redis treats as empty or out of bounds. On a three-element set:

$ redis-cli ZADD zk 1 a 2 b 3 c
(integer) 3

# start past the end of the set: Garnet writes zero bytes, redis-cli blocks on the reply
$ redis-cli ZREMRANGEBYRANK zk 3 5
^C                          # Redis: (integer) 0

# start > stop: negative count
$ redis-cli ZREMRANGEBYRANK zk 2 0
(integer) -1                # Redis: (integer) 0

# negative ranks that fall before the first element: removes the whole set
$ redis-cli ZREMRANGEBYRANK zk -100 -50
(integer) 51                # Redis: (integer) 0
$ redis-cli ZCARD zk
(integer) 0                 # Redis: (integer) 3

The -100 -50 case is silent data loss. The 3 5 case desynchronizes the connection: on GarnetStatus.OK the RESP layer forwards whatever the object wrote (libs/server/Resp/Objects/SortedSetCommands.cs:785, ProcessOutput), and the object wrote nothing, so a pipelining client reads the next command's reply as the answer to ZREMRANGEBYRANK.

Root cause

libs/server/Objects/SortedSet/SortedSetObjectImpl.cs:584-594

if (start > sortedSetDict.Count - 1)
    return;                                  // no reply written

// Shift from the end of the set
start = start < 0 ? sortedSetDict.Count + start : start;
stop = stop < 0
    ? sortedSetDict.Count + stop
    : stop >= sortedSetDict.Count ? sortedSetDict.Count - 1 : stop;

var elementCount = stop - start + 1;

Negative indexes are shifted by the set size but never floored at 0, start > stop is never rejected, and the early return leaves the RespMemoryWriter empty. elementCount is then computed from unclamped indexes, so it no longer describes what Skip(start).Take(elementCount) actually removed: -100 -50 gives start = -97, stop = -47, elementCount = 51, and Skip(-97) is a no-op, so all three members go.

Fix

Normalize the indexes before use, in the order ListObjectImpl.ListRange already uses for LRANGE (libs/server/Objects/List/ListObjectImpl.cs:143-150): shift negatives by the count, floor start at 0, reply :0 for an empty range, then clamp stop to count - 1. It is also the order zremrangeGenericCommand uses in Redis, which is worth naming here because the reply values themselves are the compatibility question.

After clamping, 0 <= start <= stop <= count - 1 always holds, so elementCount equals the number of members actually removed and every path writes exactly one reply. The count == 0 case (a set left empty by DeleteExpiredItems) now also replies :0 instead of nothing.

Test

CanDoZRemRangeByRank in test/standalone/Garnet.test.collections/RespSortedSetTests.cs, using raw RESP through LightClientRequest — a missing or duplicated reply is invisible to a StackExchange.Redis assertion.

Precisely what is red today, and what is not:

• ZREMRANGEBYRANK board 2 0 expecting :0 — fails on main (:-1). It is the first new assertion, so it is what a revert reports.
• ZREMRANGEBYRANK board -100 -50 expecting :0 — also wrong on main (:51, and board is emptied), but the run aborts at the assertion above before reaching it.
• ZCARD board expecting :3 — regression guard.
• SendCommands("ZREMRANGEBYRANK board 3 5", "PING") expecting :0\r\n+PONG\r\n — regression guard, not a red signal. On main that command writes nothing, so LightClient.CompletePendingRequests spins on a token that never arrives and the test hangs rather than fails. That is why it is ordered last, behind an assertion that fails cleanly.

None of the new commands remove anything, so the pre-existing assertions after them are unaffected.