feat(plugin-redis): add Sentinel and Cluster connection modes (#1021)

[tonghs]

Summary

Closes #1021 in full: Redis Sentinel and Redis Cluster, not just Phase 1.

Reworked on top of @tonghs's original Sentinel work, rebased onto current main. The Sentinel design changed after measurement (see below); the Cluster half is new.

What this does

A Connection Mode field on the Redis form picks Standalone, Sentinel or Cluster.

Sentinel asks the quorum which node is the primary and opens the data connection to it. It learns the quorum's other Sentinels on the first lookup, so a later one still works when the node you listed is down, and it re-checks the primary's address on every health check so a failover moves the connection with it.

Cluster reads the shard map, opens a connection to every primary, and routes each command to the shard that owns its key. It follows MOVED and ASK, splits multi-key commands across shards and recombines them, sums key counts cluster-wide, and walks every shard when browsing keys.

Pointing a mode at the wrong kind of server now says which field to change, instead of connecting and then failing on the first command. That was the issue's actual complaint: "both failure modes look like bugs rather than missing features".

Why the design is what it is

Everything below was measured against a live Redis 8.10.1 lab (6-node cluster, 3 Sentinels, a standalone primary/replica pair). Several measurements overturned the obvious design.

Failover cannot be detected from the data connection. After SENTINEL failover, the demoted primary kept reporting role:master and accepting writes with +OK for ~4.8s, and those writes were gone afterwards. No -READONLY ever arrived and master_failover_state stayed no-failover. So the address is re-checked against the quorum rather than inferred from what the node says about itself.

Transactions are off under Cluster. MULTI carries no key, so a client must pick a node before it has seen one, and Redis rejects a queued command that hashes elsewhere: MULTI; SET beta y on the wrong node gives -MOVED at QUEUED time and -EXECABORT. On three shards that kills most legal single-slot transactions. SaveChanges already runs statements serially when the flag is false, so this is a capability flag rather than new code.

Multi-key commands split by slot, not by node. The spec is explicit that the split follows hash slots "even if all the slots are managed by the same shard". Grouping by node passed every unit test and then failed against the real cluster with CROSSSLOT; the live harness caught it.

An unknown command is routed as keyless. Hashing argv[1] misroutes container commands: SCRIPT LOAD returns +OK from one node and never MOVED, so nothing corrects the guess.

The SCAN cursor names the node by cluster id. Redis accepts another node's cursor without complaint and answers with a plausible-looking page, so a cursor keyed on list position loses keys silently whenever the topology moves.

Routing comes from the server. One COMMAND call at connect (112KB, one round trip) supplies key positions and Redis 7 request/response policy tips, including the ones that only exist on a subcommand entry (COMMAND INFO config carries no tips; config|set is what says all_nodes). Redis 6 reports no tips, so the curated table fills those in rather than being replaced. COMMAND GETKEYS resolves movablekeys commands like SORT ... STORE.

No hiredis-cluster. hiredis has zero cluster symbols, but holding N contexts is fine: 6 concurrent connections over 6 threads ran 1200 commands clean, and MOVED/ASK arrive as ordinary error replies with the context still usable. That answers the issue's Q3. Q1 is one Redis type with a mode field (matching DBeaver's "Deployment"), Q2 is one aggregated keyspace (matching RedisInsight and ARDM), Q4 is one credential per plane.

CRC16 slot assignment is verified against CLUSTER KEYSLOT on 20 vectors including UTF-8, the empty key and every degenerate hash-tag case.

Fixes that ship with it

Each one makes the feature unsafe or incomplete if left out.

• Redis reported success for writes the server refused. hiredis hands -READONLY, -WRONGTYPE and the rest back as ordinary replies, and every write path discarded the reply. Measured against a real read-only replica: the grid cleared its dirty flags and the write was lost. -READONLY is exactly the signal Sentinel failover turns on, so Sentinel could not be correct while this stood.
• A command was re-sent after a read timed out. hiredis reports a read timeout as REDIS_ERR_IO, the same code as a failed write, so INCR ran twice. The write and the read are now split, and only a command that provably never reached the server, or that cannot change anything, is replayed.
• SCAN swallowed an error reply and painted "no keys". Cluster makes SCAN the main browse path.
• A plugin's own connection fields never reached the form. withBranding replaced them with the app's copy, so Redis was missing Key Separator and its whole ElastiCache IAM section, and no plugin could add a field without changing the app too.
• SET key value KEEPTTL cleared the TTL and reported OK, because an unrecognised option was dropped before the command went on the wire. Unmodelled options now pass through untouched, the way EXPIRE already did.
• Host-list connections over a tunnel. A tunnel forwards one address and the forward target came from host, which is blank whenever the form shows a host list. This affected MongoDB replica sets too.

Security

The withBranding fix has a consequence worth calling out: because the app did not know those plugin fields existed, it did not know which were secrets. A Snowflake password, a BigQuery service account key or OAuth refresh token, an Elasticsearch API key, a DuckDB token and a DynamoDB secret access key were written to the connections file in plain text and included when a connection was exported. They now go to the Keychain and are stripped from exports. Existing values move on the next save.

Verification

Check	Result
build (app + 14 bundled plugins)	PASS
test, 39 suites	252 executed, 252 passed
lint (TablePro, Plugins/RedisDriverPlugin, tests, UI tests)	0 violations
Live cluster + Sentinel harness	18/18 checks passed

The live harness drives the real channels against the lab through hiredis: routing across shards, DBSIZE summing (cluster=27 sum(nodes)=27), KEYS unioning, MGET order across shards, EXISTS summing, SCAN covering every shard, cross-slot refusal, same-slot RENAME, Sentinel resolution, quorum discovery, and both wrong-mode messages.

Not covered: plugin packaging and notarization (only a release tag runs those), and the AllPlugins aggregate, which fails on this machine inside the oracle-nio fork's @TaskLocal macro, a known local-toolchain issue unrelated to this change (zero Redis errors in that log). CI runs it.

New pure logic lives in files listed under TableProTests.sources, so it is compiled and tested rather than mirrored; PR #1215's stray TableProTests/PluginTestSources/ symlink is removed in favour of that existing convention. The UI test drives the real connection form through the three modes.

Notes

• No PluginKit ABI change. .dropdown, .hostList, .secure, visibleWhen and ConnectionStage.custom all already exist, and the @frozen FieldType/FieldSection are untouched. No currentPluginKitVersion bump, no release-all-plugins.sh.
• RedisPlugin.pluginVersion 1.0.0 → 1.1.0. Redis is bundled and also has a plugin-redis-v* registry arm.
• Cassandra loses a duplicate sslCaCertPath form field. It is the legacy spelling of the SSL/TLS pane's CA certificate, read only as a fallback, and stored values keep working.
• New user-facing strings are not yet in Localizable.xcstrings; they fall back to English, as plugin strings already do.

Fixes #1021