Fill in the neglected bitmap commands: BITFIELD, and an open-ended BITPOS - #3196

Two gaps in the bitmap family. Of the seven commands in that group, five were already covered (SETBIT, GETBIT, BITCOUNT, BITPOS, BITOP - the latter already current with the 8.2 DIFF/DIFF1/ANDOR/ONE additions from #2900). This adds the missing two, and fixes one thing BITPOS could not say.

BITFIELD / BITFIELD_RO

Previously unimplemented; the only trace in the repo was a commented-out line in the envoy exclusion list.

long?         StringBitField(RedisKey key, BitFieldOperation operation, CommandFlags flags = CommandFlags.None);
Lease<long?>  StringBitField(RedisKey key, ReadOnlyMemory<BitFieldOperation> operations, CommandFlags flags = CommandFlags.None);
// ... plus StringBitFieldAsync equivalents

with four new value types:

BitFieldEncoding.Signed(int) / Unsigned(int)
BitFieldEncoding.Int8/Int16/Int32/Int64, UInt8/UInt16/UInt32/UInt63   // + Width, IsSigned
BitFieldOffset.Bits(long) / Index(long)                              // Index is the server's #N form
BitFieldOverflow.Wrap | Saturate | Fail
BitFieldOperation.Get(enc, off) / Set(enc, off, value, overflow = Wrap) / IncrementBy(...)

Usage:

db.StringBitField(key, BitFieldOperation.IncrementBy(BitFieldEncoding.Int8, 0, 1));

using var results = db.StringBitField(key, new[]
{
    BitFieldOperation.Set(BitFieldEncoding.UInt8, BitFieldOffset.Index(3), 255),
    BitFieldOperation.IncrementBy(BitFieldEncoding.Int16, 64, -1, BitFieldOverflow.Saturate),
    BitFieldOperation.Get(BitFieldEncoding.UInt63, 0),
});

Design notes

• Signedness belongs with the width, not in a flags enum. u8 is one wire token and one semantic unit; overflow is a separate, sticky, kind-scoped concept that GET ignores entirely. A single flags bag would permit Signed | Fail on a Get, where half is meaningless. A named encoding type also stops (width, offset) transposition, both being bare integers otherwise.
• #N belongs on the offset, for the same reason: a flag that reinterprets a different argument is the hazard, not the ceremony.
• Results are plain long. Every legal encoding is i1-i64 or u1-u63, and u63's maximum is exactly long.MaxValue - which is why u64 does not exist (the reply is a signed 64-bit integer). So there is nothing to disambiguate and no need for a struct with signed/unsigned accessors. Elements are nullable only because OVERFLOW FAIL reports a nil for the operation it skipped; the batch itself is non-null - the reply is always an array with one element per operation, so an empty lease covers both an empty batch and a non-observable result such as fire-and-forget.
• There is a named UInt63 where UInt64 would sit. The double-take is the point: it documents the ceiling exactly where someone reaches for the obvious thing, and Unsigned(64) throws with a message naming UInt63 and Int64 as the alternatives.
• OVERFLOW is emitted only when it changes, and never for a leading run of WRAP (the server default). The sticky state is neither reset nor consumed by an intervening GET, so the tracker carries across them.
• All-GET batches go out as BITFIELD_RO when the selected server is 6.0+ and the command is not disabled/renamed, so a replica can serve them; anything that writes stays as BITFIELD, which is primary-only (the server treats BITFIELD as a write even when every sub-operation is a GET - hence BITFIELD_RO existing at all). Write ops are detected client-side, so BITFIELD_RO is never issued with something it would reject.
• Retry category follows the payload, on a separate axis from routing: ReadOnly when every sub-operation is a GET (whichever of the two commands is issued - the server treating BITFIELD as a write governs which servers accept it, not whether replaying is safe), WriteLastWins when there is no INCRBY (SET is positional, so a replay lands on the same value), and WriteAccumulating otherwise. Follows the existing "demoted where we can see the args" pattern from XADD.
• An empty batch short-circuits locally to an empty lease - no round-trip.
• A default(BitFieldEncoding) is rejected at operation construction and in the writer, so a default(BitFieldOperation) sitting in an unfilled array cannot reach the wire as i0.

Not included, deliberately - both non-breaking to add later if wanted: scalar StringBitFieldGet/Set/Increment helpers (the single-op overload subsumes them; the only loss is long? rather than long for a pure Get), and public accessors on BitFieldOperation (Kind/Encoding/Offset/Value/Overflow are internal).

The command is rendered by a Message subclass in WriteImpl (the HotKeysStartMessage shape) rather than via an intermediate RedisValue[], so the batch form aliases the caller's memory and the single-operation form holds the operation inline; sub-command and overflow tokens are framed u8 spans written raw, and the encoding is one framed write into a scratch buffer. Verified against the IL on all six TFMs that neither path allocates - notably, a [operation] collection expression does allocate a one-element array on every framework without the by-ref span constructor (net461, netstandard2.0, net472, net6.0), so that path takes in BitFieldOperation instead.

The two StringBitField overloads need #pragma warning disable RS0026, with the same "disambiguated via parameter types" justification already used in RedisChannel.

StringBitPosition: an open-ended end

StringBitPosition always sent an explicit end, and for a clear-bit search the server distinguishes the two cases:

BITPOS key 0        -> 8     # first clear bit past the end of the string
BITPOS key 0 0      -> 8     # start alone: still open-ended
BITPOS key 0 0 -1   -> -1    # explicit range: no clear bit in the string

(single all-ones byte). The end parameter documented -1 as "unlimited", which was the wrong mental model - -1 is the last byte, and the open-ended result was unreachable.

Passing StringIndex.Unbounded as end now omits it. That requires StringIndexType.Byte, since BYTE/BIT is only legal after an explicit end; silently dropping the token would reinterpret start from bits to bytes, so it throws instead.

A sentinel rather than an overload because a no-end overload would be equally applicable to the existing one at every call site, with both needing defaults substituted - i.e. CS0121 for callers. The sentinel also costs no new interface members and flows through the legacy overload, IBatch/ITransaction and the keyspace-isolation wrappers for free.

BITCOUNT is untouched: its start/end are an inseparable pair on the wire (BITCOUNT key 0 is a syntax error), so a sentinel there could only silently discard start, and 0 -1 is anyway equivalent to no range.

Testing

• Exact-bytes round-trip tests (no server): OVERFLOW dedup and stickiness across a GET, the #N and i64/u63 tokens, nil parsing, payload classification, BITFIELD_RO vs BITFIELD primary-only-ness, and the BITPOS omitted-end layout.
• Type unit tests: width limits and their messages, offset forms, default/unknown-value rejection.
• Live integration: SET/GET/INCRBY semantics, OVERFLOW FAIL nils, index offsets, the empty batch, and a profiler assertion that all-GET calls left as BITFIELD_RO to the replica while the write left as BITFIELD to the primary.

dotnet build Build.csproj -c Release /p:CI=true is clean across all TFMs. Full suite on net10.0: 6022 passed, 149 skipped, with one failure that differs run-to-run (RetryTests.WithRetry_FailsOverBetweenGroupsOnLoading once, InProcPubSubTests.TestBasicPubSub once; each passes in isolation) - neither touches bitmaps, and both look like pre-existing flakiness under parallel load rather than anything here, though I have not bisected them.