Fix cache instance divergence when custom ConnectionProvider is used with client builders

[AmariahAK]

Fixes #4588

What was the issue

When a custom ConnectionProvider is passed to a client builder (e.g. MultiDbClient.builder().connectionProvider(myProvider).build() or RedisClient.builder().connectionProvider(p).build()), and that provider internally carries a Cache, UnifiedJedis.getCache() returns null. The connections use client-side caching, but the client API reports none — the cache instance diverges.

Where was the issue

In AbstractClientBuilder.build(). The builder's cache field is only populated via .cache() / .cacheConfig(). When a custom provider is injected via .connectionProvider(...), the builder skips createDefaultConnectionProvider() (which would have passed the builder's cache) and passes this.cache (still null) directly to the client constructor. Meanwhile, the custom provider — built externally with a cache — creates cache-enabled connections, creating a mismatch.

How it was fixed

Three small, orthogonal changes:

1. ConnectionProvider interface — added default Cache getCache() returning null (safe for all existing implementations that don't use cache).

2. Four provider implementations — each now stores and exposes its cache via @Override getCache():

   • MultiDbConnectionProvider — already had the field, just added the getter
   • SentineledConnectionProvider — already had the field, just added the getter
   • PooledConnectionProvider — now stores the cache (was previously passing it to the pool but discarding the reference)
   • ClusterConnectionProvider — now stores a separate clientSideCache field alongside the existing JedisClusterInfoCache cache

3. AbstractClientBuilder.build() — after the provider is finalised, if this.cache is still null, pull it from connectionProvider.getCache(). This bridges the gap: a custom provider's cache now reaches UnifiedJedis.

Why this approach

• Minimal diff — one new interface method (with a safe default), one per-provider getter, five lines in the builder.
• No API breakage — default method means all existing ConnectionProvider implementations compile unchanged.
• Reuses existing patterns — ConnectionProvider already has default methods (getConnectionMap, getPrimaryNodesConnectionMap); this follows the same pattern. The builder already has type-specific knowledge of providers; the getCache() bridge is in that same spirit.
• Covers the future — any ConnectionProvider implementation that holds a cache can override getCache() and the builder will pick it up automatically.

How to test locally

# Unit tests (no Redis needed):
mvn -Dtest=CustomProviderCacheTest test

# Integration tests (requires Docker):
make start version=8.6
mvn -Dtest=MultiDbCSCTest test
make stop

# Existing MultiDbCacheTest integration tests:
make start version=8.6
mvn -Dtest=MultiDbCacheTest test
make stop

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Additive API (default getCache()) and builder wiring only; no auth or connection semantics change beyond exposing the existing cache reference.
> 
> **Overview**
> Fixes **cache instance divergence** when clients are built with a **custom `ConnectionProvider`** that already enables client-side caching: connections use CSC, but **`getCache()` returned `null`**.
> 
> **`ConnectionProvider`** gains a default **`getCache()`** (null when unused). Built-in providers (**`PooledConnectionProvider`**, **`ClusterConnectionProvider`**, **`MultiDbConnectionProvider`**, **`SentineledConnectionProvider`**) override it; **`PooledConnectionProvider`** now keeps the cache reference (and can read it from **`ConnectionFactory`**). **`ConnectionFactory`** exposes **`getCache()`** for the cache wired at build time.
> 
> **`AbstractClientBuilder.build()`** copies **`connectionProvider.getCache()`** into the builder’s cache when no explicit **`.cache()`** / **`.cacheConfig()`** was set, so **`UnifiedJedis.getCache()`** matches the provider’s cache.
> 
> Adds **`CustomProviderCacheTest`** and asserts **`getCache()`** in **`MultiDbCSCTest`**.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit cc7b5c8c9f95281b6b1ae3a2f3279494d8cb25c4. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 361bf2029f

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c8132f3c21

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[ggivo]

@AmariahAK

The team is stretched right now and may take some time before we get to it.

Adding @atakavci to take a look as well.
I know you will be off next week. Just in case you have some time.

[AmariahAK]

@ggivo no worries, thanks for taking time to review regardless.
If you need any changes, feel free to tell me.