Add support for CONFIG GET and SET commands in UnifiedJedis

[uglide]

Note

Medium Risk
Adds new CONFIG GET/map-based CONFIG SET APIs that can mutate Redis server configuration and have non-obvious behavior in OSS Cluster (keyless command routed to a single shard). Changes are additive but touch server-management command execution and add new integration coverage across topologies/RESP versions.

Overview
UnifiedJedis now exposes CONFIG GET (single and varargs patterns) and a new overload of CONFIG SET that accepts a Map<String,String> for setting multiple parameters in one call.

CommandObjects adds the corresponding CommandObject builders (using BuilderFactory.STRING_MAP for GET and iterating map entries for SET), and the PR introduces new mocked tests plus integration test suites that run against both standalone and OSS Cluster for RESP2/RESP3, including wildcard/unknown-parameter cases and multi-parameter set/restore behavior.

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

[github-actions]

Test Results

  197 files  + 2    197 suites  +2   8m 59s ⏱️ -33s
7 319 tests +24  6 469 ✅ +24  850 💤 ±0  0 ❌ ±0 
7 327 runs  +24  6 469 ✅ +24  858 💤 ±0  0 ❌ ±0 

Results for commit 063e4de. ± Comparison against base commit e390965.

♻️ This comment has been updated with latest results.

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[ggivo]

Do we want/need to expose CONFIG GET/SET for RedisCluster as well?

CONFIG GET responses can differ across nodes and cannot be meaningfully aggregated. If exposed on RedisCluster, the default behavior would effectively be executing against a random node, which may be surprising.

How about exposing CONFIG GET/SET only for RedisClient for now and marking them as experimental?