Updates in default connection and retry settings

[petyaslavova]

Connection configs

This PR updates the default connection behavior for redis-py clients.
TCP keepalive is now enabled by default, and unspecified keepalive options resolve to platform-supported defaults: 30s idle, 5s interval, and 3 probes. The default socket timeout and socket connect timeout are now both 5 seconds.

The default socket read buffer size is reduced to 32kB, and the default connection pool limit is reduced from the previous effectively-unbounded value to 100 connections.
These defaults are applied across sync and async connection paths, with async cluster connection limits aligned as well.

Retry configs

The default retry policy now uses ExponentialWithJitterBackoff(base=0.01, cap=1) with 10 retries.
This gives standalone retry paths a 10ms base backoff, a 1000ms cap, and more retry attempts before surfacing retryable failures.

Cluster retry defaults are aligned to 10 attempts as well. For regular cluster commands, the retry object is still primarily used as a retry-count container, allowing more topology recovery attempts; cluster transactions use the full retry object and therefore honor the jittered backoff configuration.

Fixes #2243 and #2220

---

Note

High Risk
Changing library-wide defaults for timeouts, pooling, keepalive, and retry counts can break deployments that implicitly relied on unbounded waits, huge pools, or fewer retries—behavior shifts without code changes at call sites.

Overview
This PR changes default client behavior for new Redis, async, cluster, multidb, and HTTP clients when callers do not override settings.

Connections: Default socket_timeout and socket_connect_timeout are now 5 seconds (was often unlimited/None). TCP keepalive is on by default, with socket_keepalive_options resolving to platform-supported values (30s idle, 5s interval, 3 probes) unless None/{} is passed. Parser read buffer defaults drop from 64KiB to 32KiB. Connection pool and async cluster per-node max_connections default to 100 instead of an effectively unbounded value.

Retries: Default policy becomes Retry(ExponentialWithJitterBackoff(base=0.01, cap=1), retries=10) (was base=1, cap=10, 3 retries). Cluster cluster_error_retry_attempts defaults to 10; docs and examples are updated to match.

Internals: Shared defaults live in redis/_defaults.py; the omitted-argument SENTINEL is consolidated under redis.utils (parsers/async connection stop defining their own). Tests add tests/test_defaults.py and adjust maintenance/cluster tests for the new timeout and retry expectations.

^{Reviewed by Cursor Bugbot for commit 1b837bb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit aeb2e4b. Configure here.}

[elena-kolevska]

Can't we extract the creation of a

[elena-kolevska]

Seems like this wasn't finished. We have the default retry object instantiated in too many palces with magic number. Let's centralise it with some kind of a get_default_retry() factory.

[elena-kolevska]

Will this affect blocking commands? Do we dynamically change/disable the socket timeout on those connections?

[elena-kolevska]

I feel like this should be configurable on the Client level, because it can be problematic for users with huge keys.