feat: expose sslSocketFactory, sslParameters, and hostnameVerifier on RedisStoreBuilder

[joff9]

Expose SSL configuration options on RedisStoreBuilder

The JedisPool constructor accepts sslSocketFactory, sslParameters, and hostnameVerifier for customizing TLS behaviour, but all three were hardcoded to null in RedisStoreImplBase, making them unreachable by callers.

This PR exposes all three as builder options on RedisStoreBuilder.

Changes

• Added sslSocketFactory(SSLSocketFactory), sslParameters(SSLParameters), and hostnameVerifier(HostnameVerifier) methods to RedisStoreBuilder
• Wired the new fields through to the JedisPool constructor in RedisStoreImplBase
• All three are no-ops when TLS is not enabled

---

Note

Medium Risk
Changes affect how TLS Redis connections are established; misconfigured custom SSL or hostname verification could weaken security, though behavior is unchanged unless callers opt in.

Overview
RedisStoreBuilder now lets callers pass SSLSocketFactory, SSLParameters, and HostnameVerifier for TLS Redis connections, matching what JedisPool already supports.

Previously RedisStoreImplBase always passed null for those three constructor arguments, so custom trust stores, cipher suites, or hostname checks were impossible without forking. The new builder fields are forwarded into JedisPool; when TLS is off they are documented as ignored, and unset values still defer to JVM defaults.

Unit tests cover default nulls and that each setter stores the configured instance.

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

[tanderson-ld]

Thank you for the contribution. I'm reviewing your changes and so far they look good to me. Would you mind providing context for us about your use case that motivated this so we can consider it for our other languages and ecosystems?

[joff9]

Thank you for the contribution. I'm reviewing your changes and so far they look good to me. Would you mind providing context for us about your use case that motivated this so we can consider it for our other languages and ecosystems?

Thank you for reviewing the changes!

This was for allowing us to connect to a Valkey instance whose TLS certificate is signed by an internal private CA that isn't in the JVM truststore, so it was needed to provide a custom SSLSocketFactory backed by a trust store that contains our CA certificate.

[tanderson-ld]

Should now be available in launchdarkly-java-server-sdk-redis-store 3.2.0.

Thank you!