GH-3110: Redis transport supports caller-managed ConnectionMultiplexer / ConfigurationOptions

[jeremydmiller]

Closes #3110.

Problem

Wolverine.Redis could only be configured with a connection string, so it always created and owned the ConnectionMultiplexer internally. That blocks token-based auth — Azure Managed Redis with Entra ID / Managed Identity (via Microsoft.Azure.StackExchangeRedis) — because when an access token expires the app must be restarted; the underlying multiplexer can be neither replaced nor reconfigured.

Approach (modeled on the Azure Service Bus transport)

ASB supports several construction modes (UseAzureServiceBus(connectionString), UseAzureServiceBus(namespace, TokenCredential), ...) by storing whichever inputs were supplied and building one client from them. This PR gives Redis the same shape — two new UseRedisTransport overloads matching the exact API requested in the issue:

opts.UseRedisTransport(ConfigurationOptions options);       // Wolverine builds & owns the multiplexer
opts.UseRedisTransport(IConnectionMultiplexer multiplexer); // caller-managed; Wolverine never disposes it

RedisTransport now holds exactly one of three connection sources (caller-managed multiplexer > ConfigurationOptions > connection string) and resolves a single shared connection lazily from it. Key behaviors:

• A caller-managed IConnectionMultiplexer is used as-is and is never disposed on shutdown — the caller owns its lifetime and any token-refresh background work. The connection-string / ConfigurationOptions multiplexers are still owned and disposed by Wolverine.
• ResourceUri, ConnectionSummary, and connect-logging derive from whichever source is configured; passwords are masked (and a caller-managed multiplexer is reported as such, since Wolverine never sees its credentials).
• The existing connection-string overload and behavior are unchanged.

Why this solves token refresh

With ConfigurationOptions or a caller-managed multiplexer, Wolverine never has to recreate the connection from a static connection string, so Microsoft.Azure.StackExchangeRedis can refresh the Entra token in place — no pod restart on expiry.

Tests

redis_connection_source_configuration covers all three modes: caller-managed multiplexer reused and never closed/disposed, password masking for connection string + ConfigurationOptions, ConfigurationOptions building a working connection, and an end-to-end round-trip with a caller-managed multiplexer that survives host disposal. Existing pub/sub + diagnostics + non-default-database tests still pass.

Docs

Adds a Connection Options section to the Redis transport guide, including the Azure Managed Redis / Entra ID example.

🤖 Generated with Claude Code