Add RedisValue.EqualityComparer, with an opt-in binary reading

[mgravell]

Stacked on #3228; retarget to main if that lands first. Replaces the approach in #3229, which I closed.

Why this shape

RedisValue equality works on the text a value decodes to — that is what lets a blob equal the string it
spells, and GetHashCode hashes the same decoded form to stay consistent with it. For callers moving large
payloads that reading costs more than they need.

#3229 tried making the type itself cheaper, and #3116 tried making its Equals byte-based. Both run into the
same wall: RedisValue.Equals(object) accepts a string, and RedisValue.GetHashCode() currently agrees with
string.GetHashCode() for the same text, so a Hashtable keyed by RedisValue and probed by string works
today. Changing either half silently breaks that, and it is not a change that belongs outside a major.

A comparer sidesteps it entirely: it owns both halves of its own contract, so the byte reading is
self-consistent within it, and nothing changes for anyone who does not ask.

var byBytes = new Dictionary<RedisValue, T>(RedisValue.EqualityComparer.Binary);

Shape

An abstract base with Default and Binary, implementing IEqualityComparer<RedisValue> and the untyped
IEqualityComparer. The untyped side accepts whatever RedisValue itself accepts from object — string,
byte[], the numerics — through the same forgiving TryParse that Equals(object) uses, rather than
demanding a boxed RedisValue.

Derivation is closed via a private protected constructor. Nobody needs to derive from this to write their own
rules — IEqualityComparer<RedisValue> is right there — and leaving it open would fix the shape permanently.
(closed would say this more directly but is C# 15; we are on 14.)

Equality only, deliberately. A total order would have to choose between the numeric, textual and raw-byte
readings of a value, and those disagree for the same logical value. Redis does not define one either: sorted
sets order by score, and ZRANGEBYLEX orders member bytes rather than values. If ordering is ever wanted it
should be named for its domain rather than offered as a general "comparer".

Where Binary differs from Default

It agrees with Default for text that is well-formed and not numeric, and differs in three places:

• Numeric text. operator == runs Simplify() first, so "1.0", "1.00" and "1" are all equal under
  the default rules, as are "0" and "-0.0" and "1e2"/"100". Binary compares the bytes, so they are
  not — which is how the server identifies members.
• Unpaired surrogates. A string holding one encodes to the same bytes as one holding U+FFFD, so Binary
  calls those equal and Default does not.
• Non-canonical UTF-8. A blob that does not re-encode to itself (0xFF, which decodes to U+FFFD) is
  distinct from that text under Binary, where Default calls them equal.

Each of the three arrived the same way: a differential test failing on a case I had not thought of, after
documentation that claimed fewer of them. All three are now pinned.

A property worth having: Binary does not depend on storage

Binary reads the UTF-8 form of both sides, so the same text equals itself however it arrived. The default
rules do not manage that for every input — see #3233, where a string and the bytes of that same string can
simplify differently, to the point that a value written with StringSet does not equal the value read back by
StringGet. Binary is unaffected, and there is now a test holding that.

Numbers

Against Default on the same matrix (net10.0, string vs byte[]):

Size	Form	Default	Binary
16	Equal	56.3 ns	10.8 ns	5.2×
1024	Equal	131.9 ns	41.1 ns	3.2×
1024	DiffAtStart	54.9 ns	15.2 ns	3.6×
65536	Equal	5,397 ns	2,155 ns	2.5×
65536	DiffAtStart	52.4 ns	15.5 ns	3.4×
65536	DiffAtEnd	5,793 ns	1,932 ns	3.0×

Hashing is the bigger story, since it never decodes: 30.4 → 4.5 ns (16B), 503.7 → 28.2 ns (1KB),
31,026 → 884 ns (64KB, 35×). Blob-against-blob: 34.6 → 5.8 ns at 16B, and 38.7 → 5.6 ns for an early
mismatch at 64KB.

Two defects the benchmarks caught that the tests could not have:

1. Binary was initially 61× slower than Default for an early mismatch at 64KB (3,213 ns vs 52 ns),
   because it materialised both byte forms before comparing anything. It now encodes the string a chunk at a
   time directly onto the blob's own bytes.
2. The GetByteCount() precheck was the floor rather than the comparison — measuring a string's UTF-8 length
   walks all of it. Moving it behind the fast paths took 64KB/DiffAtStart from 897 ns to 15.5 ns.

Testing

Default is asserted to match the type's own == and GetHashCode exactly, so it is a true no-op wrapper.
Binary is asserted to agree with Default on everything that round-trips, to diverge in exactly the two
documented ways, to be self-consistent (equal implies equal hash) across malformed UTF-8 and segmented blobs,
and to work as a Dictionary comparer. The untyped API is covered for string/byte[]/RedisValue and for
inputs it cannot read.

Full suite: 6372 passed, 0 failed. All six TFMs build with 0 warnings.

Review round

An external review found a real defect that my tests could not reach, plus a documentation error. Both fixed
here; recording them because the first is the kind of thing worth knowing about the shape of the code.

The chunk-boundary surrogate guard was wrong. StringEqualsBytes encodes 512 characters at a time, and
the guard against splitting a surrogate pair extended the chunk by one character. That fails twice over: 511
three-byte characters followed by a straddling pair need 1537 bytes of a 1536-byte buffer, so
Encoding.UTF8.GetBytes throws ArgumentException; and where the character at the seam is itself a lone high
surrogate, the extra character is the following pair's high half, so a real pair gets split and an equal
value compares unequal. Stepping back instead fixes both, and cannot reach zero because it is only reachable
when take == ChunkChars.

Fuzzing a 500–530 character corpus over the awkward alphabet: 247 wrong in 20,000 before, 0 after, no
exceptions either side of the fix.

The tests could not have caught it — the longest value in the corpus was 300 characters, so the chunking loop
never ran past its first pass. There are now cases placing a straddling pair, a lone high surrogate before a
real pair, and a pair approached from the other side at exactly the 512-character seam.

Also from that review: numeric divergence was missing from the remarks entirely (above); the seed now comes
from RandomNumberGenerator rather than Guid.NewGuid, whose version and variant bits are fixed; and two
ordinally-equal strings now take a cheap exit, since identical text encodes identically.

Declined: a shortcut comparing same-type numbers on their raw values, because negative zero formats
differently from how it compares, and byte semantics are the entire point of Binary.