feat(redis): add Redis Sentinel support

[PAzter1101]

Summary

Adds connection-level Redis Sentinel support to RedisBroker, addressing #1812.

broker = RedisBroker(
    sentinels=[("sentinel-1", 26379), ("sentinel-2", 26379)],
    sentinel_master_name="mymaster",
)

What changed

• New broker params (RedisConnectionParams): sentinels, sentinel_master_name, sentinel_kwargs. Extracted in RedisBroker.__init__; a missing sentinel_master_name raises SetupError. Excluded from cluster params.
• RedisConnectionState gains an optional SentinelConfig. When set, connect() builds the client via redis.asyncio.sentinel.Sentinel(...).master_for(...) instead of a plain ConnectionPool. The resulting SentinelConnectionPool re-discovers the current master on every reconnect, so publishers and stream (XREADGROUP) consumers fail over for free — both already go through connection.client.
• Stream subscriber busy-loop fix: the stream _consume loop had no backoff in its except (unlike the base channel/list loop), so it would hot-loop on a persistent ConnectionError (e.g. during a master failover). Extracted the existing 5s backoff into a shared CONSUME_ERROR_BACKOFF_SECONDS and applied it in both loops.
• Tests: unit tests that need no running Sentinel — assert the broker builds the right SentinelConfig, that direct mode is unaffected, validation, and that connect() actually yields a SentinelConnectionPool. New redis_sentinel pytest marker.

mypy --strict, ruff check, ruff format --check and the new unit tests pass locally.

Scope / follow-ups

This is the connection-level MVP outlined in #1812 (publishers + simple commands + streams). Intentionally not in this PR, to keep it focused:

• Pub/Sub (channel) resubscribe after failover. A channel subscriber holds a long-lived pubsub() subscription; rebuilding and resubscribing it on failover is a separate change and is left as a follow-up. (Stream consumers recover because each xreadgroup re-acquires a connection from the Sentinel pool.)
• Integration tests against a real Sentinel (a compose service + CI job mirroring the existing redis-cluster setup). The tests here are unit-level.

Refs #1812.

[CLAassistant]

All committers have signed the CLA.

[pbonneaudiabolocom]

Hi,

Thanks for the hard work.

Seeing the PR for redis cluster, I wonder if it would not be "better" to create a RedisSentinelBroker than to add parameters to the generic RedisBroker.

It would prevent these param to be available in redisCluster as well, and it would somehow keep the same logic where you just switch from one broker to the other one when changing technology.

What do you think ?

[PAzter1101]

Thanks for the suggestion — agreed. I've reworked it into a dedicated RedisSentinelBroker (plus RedisSentinelRouter for the FastAPI integration), mirroring RedisClusterBroker from #2854. The Sentinel params now live only on the Sentinel classes and no longer leak into RedisBroker/RedisClusterBroker. The earlier "params on RedisBroker" commits are kept in the history for context.