[toronik]

Forward-port of #12 (released as 5.6.3 from release/5.6.x) to the 6.x line, bumped to 6.1.1. Cherry-picked cleanly onto 6.1.0; :env-redis:compileTestKotlin passes locally on Testcontainers 2.

What

• RedisSystem gains exec(f: (KredsClient) -> T) and default data helpers built on it:
  keys(pattern, vararg types), type, del, exists(vararg), exists(key), getMap,
  setMap(key, field, value), setMap(key, map), getList(key, start, stop), setList, get, set.
  Signatures and behaviour are the ones RedisContainerSystem had; it now only overrides exec and clean.
• ResettableRedisRemote is public. Its exec opens a client and runs SELECT env.redis.database
  before every call, so every helper stays inside its own logical database. keys() hides the
  __ns_owner__ marker that start() writes, so a spec sees the same key set as against a container.
  start() and clean() go through the same exec.
• resettableRedis(props) now returns RedisSystem — no as RedisSystem cast needed.

Why

In the shared test stack, specs run against a Redis sidecar via resettableRedis(props). Up to 5.6.2 it
could only do clean(), while MD specs call keys(), getMap(), setMap() that existed only on
RedisContainerSystem. As a result every repo wrote its own RoomRedis wrapper
(quotes/dataflow, securities-api, md-cbonds-quotes). With 5.6.3 specs use env<RedisSystem>() and the
same calls work in CI (container) and in the room (remote).

Compatibility

• Source: existing callers of RedisContainerSystem helpers compile unchanged (same names, defaults,
  return types; del/exists(vararg)/getList/setList now declare the types they already returned).
• Binary: the 5.6.2 JVM method ResettableRedisRemoteKt.resettableRedis(Map): ExternalSystem is kept as a
  hidden bridge; the new Kotlin-visible function is compiled as resettableRedisSystem (checked with javap).
  Callers compiled against 5.6.2 keep linking; on recompile they get the RedisSystem return type.
• Binary, not kept: the default-argument statics RedisContainerSystem.keys$default / getList$default
  moved to RedisSystem$DefaultImpls. A jar compiled against 5.6.2 that calls keys() / getList(key)
  without arguments would get NoSuchMethodError until recompiled. Specs are always recompiled; no
  precompiled consumer was found in the platform jars.

How it was tested

• ResettableRedisRemoteTest — one test per helper plus "writes/reads its own db, db 0 untouched",
  resettableRedis() returns RedisSystem, exec runs in its own db; the 3 existing start/clean tests kept.
  Testcontainers Redis by default; with ENV_REMOTE=true it uses a running Redis
  (TEST_REDIS_HOST/TEST_REDIS_PORT, default redis:6379, db TEST_REDIS_DB), touching db 0 only with a
  uniquely named guard key that it removes afterwards.
• Red run: the new test against unchanged 5.6.2 sources doesn't compile (class private, helpers unresolved).
• Green run: ./gradlew :env-redis:test --tests redis.ResettableRedisRemoteTest with ENV_REMOTE=true against
  the shared-stack Redis — 12/12 passed, 0 skipped (twice).
• :env-redis:detekt :env-redis:ktlint :env-redis:compileTestKotlin :example:compileTestKotlin — green.
• Not run: RedisContainerSystemTest and the Testcontainers branch of ResettableRedisRemoteTest —
  there was no Docker on the machine (/var/run/docker.sock missing). GitHub Actions CI (./gradlew build) covers them.

🤖 Generated with Claude Code

🤖 Generated with Claude Code