spring-kotlin docker-backed integration test

[rossdanderson]

Parent

#65

What to build

Give examples/spring-kotlin a docker-backed integration test that proves the Spring starter serves
data end-to-end through a live Liberator, modelled on the shape of application-apis'
CalendarAdapterIntegrationTest (Liberator Testcontainer → real adapter against the mapped DataSource
port → StreamLink client assertions via Turbine).

• Add an integrationTest JvmTestSuite depending on datasourcex-kotest, the Kotest runner, and
  Turbine. It is not wired into check, and Kover instrumentation is disabled for it — so CI
  (no Docker registry) never runs it; developers run :spring-kotlin:integrationTest on demand.

• No production change to the example. The adapter is pointed at the container's mapped DataSource
  port purely by overriding a startup property. The following shape came from the prototype in spring-kotlin docker-backed integrationTest design #64
  and encodes the key decision (start-the-real-adapter-via-config, then assert through a StreamLink
  client):

  val liberator = install(LiberatorContainerExtension())
  val ctx = SpringApplicationBuilder(SpringKotlinApplication::class.java)
      .properties("caplin.datasource.managed.peer.outgoing=" +
          "ws://${liberator.containerState.host}:${liberator.dataSourcePort}")
      .run()
  // liberator.connect("alice").getSubject<Payload>(Subject("public","stream","foo","42"))…

• Assert: the public Payload stream (first item version 0, parameter1="foo", parameter2=42,
  non-null uuid; next item version 1); the public container's initial Bulk of 10 rows; and the
  USER_ID / persistent-session token injection reaching the payload. Proving USER_ID overrides the
  path requires a Liberator object-map (%u) override supplied via DefaultContainerConfig(adapterConfig = …),
  and the session assertion requires establishing a persistent session — validate these while building.

Acceptance criteria

• examples/spring-kotlin has an integrationTest source set depending on datasourcex-kotest.
• The suite is excluded from check and from Kover; ./gradlew check does not start a container.
• The test starts the real spring-kotlin adapter against the container's mapped port via configuration only (no production-code change).
• It asserts the public Payload stream and the container's 10-row bulk end-to-end.
• It asserts the injected USER_ID and persistent-session id thread into the payload.
• :spring-kotlin:integrationTest passes locally against a real Liberator.

Blocked by

• Shared datasourcex-kotest test-support module #69

[rossdanderson]

Implemented on branch sl4jx-consolidation (commit 36bfa35). Added an integrationTest JvmTestSuite to examples/spring-kotlin depending on datasourcex-kotest + kotest-runner/assertions + turbine, plus SpringKotlinIntegrationTest. The suite is not wired into check (JvmTestSuite isn't auto-attached) and the example isn't in Kover aggregation, so ./gradlew check starts no container; developers run :examples:spring-kotlin:integrationTest on demand.

The example starts unchanged via SpringApplicationBuilder, pointed at the container's mapped DataSource port with a single command-line override (--caplin.datasource.managed.peer.outgoing=ws://<host>:<mappedPort>) — passed as a CLI arg, not .properties(...), so it outranks the example's application.properties. No production-code change.

Asserts end-to-end through a live Liberator: public Payload stream (version 0→1, parameter1="foo", parameter2=42, non-null uuid), the public container's initial 10-row bulk, and the injected USER_ID ("alice") + persistent-session id reaching the payload.

Note on the USER_ID/session override: rather than a DefaultContainerConfig(adapterConfig=…) %u override, this relies on the object maps the Spring starter auto-registers from @IngressDestinationVariable — the client subscribes to /user/stream/foo/42 and /session/stream/foo/42 and Liberator injects %u/%g (confirmed in the adapter logs: /user/stream/%1/%2 -> /user/%u/stream/%1/%2, /session/stream/%1/%2 -> /session/%u/%g/stream/%1/%2). All 4 tests pass locally against a real Liberator.