fix(testkit): replace the deleted minio/minio fixture image with adobe/s3mock

[fupelaqu]

Closes #323

Why

minio/minio has been deleted from Docker Hub, so the four *CopyIntoS3Spec suites abort before their first test, inside MinioTestKit.start():

org.testcontainers.containers.ContainerFetchException:
  ... pull access denied for minio/minio, repository does not exist or may require 'docker login'

Measured, so it is neither a rate limit nor a login problem: docker pull minio/minio:latest fails the same way on a developer machine as on the runner, and https://hub.docker.com/v2/repositories/minio/minio/ returns 404 (a throttle returns 429, an auth problem 401). Nothing in this repository changed. CI run that caught it: https://github.com/SOFTNETWORK-APP/SoftClient4ES/actions/runs/34655370845/job/103446486136

What changed

The fixture image becomes adobe/s3mock:5.2.2, driven by a hand-rolled Testcontainers GenericContainer. Only the tracked template testkit/.../MinioTestKit.scala is edited; the four es{6,7,8,9}/testkit copies are generated by copyTestkit() and gitignored, so they follow automatically. The trait keeps its name, so the four concrete specs and CopyIntoS3IntegrationSpec are untouched; renaming it to S3TestKit is a deliberate follow-up.

Rejected on measurement, not preference:

• LocalStack — the current image is Pro-gated: localstack/localstack:latest (2026.8.2) exits code 55 with License activation failed. Unusable as an unauthenticated CI fixture.
• The quay.io MinIO mirror — its newest community tag is RELEASE.2025-09-07T16-13-09Z; everything newer is a .hotfix.* build. It would pin the suites to a frozen AGPL binary from a vendor that has already closed one of its two channels.
• The s3mock-testcontainers module — 5.2.2 is Java-17 bytecode built against Testcontainers 1.21.3, while this build's default JDK is 11 and it pins Testcontainers 2.0.2. GenericContainer avoids both.

adobe/s3mock:5.2.2 is ~84 MB, serves in about 2 s, declares no EXPOSE (buildpacks image, so withExposedPorts(9090) is required), and seeds buckets from COM_ADOBE_TESTING_S3MOCK_STORE_INITIAL_BUCKETS.

Two protections the swap removes, and their replacements

(a) Bucket seeding is silently fallible. Adobe renamed the seeding property between 4.x and 5.x. Passing the old name is invisible: the container starts, answers 200 on /, and lists no buckets. start() now asserts the bucket exists and names the env var when it does not. The obvious probe would have been vacuous: fs.exists("s3a://<bucket>/") returns true against a container with no buckets, because S3A answers the root path from a synthetic directory status and fs.s3a.bucket.probe defaults to 0.

(b) s3mock does not verify credentials at all, where MinIO answered 403. The testkit's system properties are what exercise the documented AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY contract (documentation/sql/dml_statements.md:364-375) end to end, and nothing else in the repository asserts that propagation. Replaced by a unit assertion in LocalPathSpec on the resulting fs.s3a.access.key, fs.s3a.secret.key, fs.s3a.endpoint and fs.s3a.path.style.access.

Both gates were shown failing before passing:

gate	mutation	result
(a)	the 4.x env-var name restored	suite ABORTS: S3 bucket 'copy-into-test' does not exist on adobe/s3mock:5.2.2 ... seeds buckets from the env var '...' - check that name
(a)	AWS_ENDPOINT_URL misspelled in start()	suite ABORTS with the other diagnosis, Could not reach the S3 bucket
(b)	envOrProp narrowed to sys.env only	1 of the 2 new LocalPathSpec tests red, read credentials and endpoint from JVM system properties; the no-static-key test correctly stays green

Verification

Four *CopyIntoS3Spec suites 3/3 each on real Elasticsearch 6.8.23 / 7.17.29 / 8.18.3 / 9.0.3; core/test 981/981 (43 suites); LocalPathSpec 43/43; ++ 2.12.20 core test compile and testkit compile; headerCheck, scalafmtSbtCheck, scalafmtCheck, test:scalafmtCheck green from a cold cache. An independent reviewer re-ran both mutations and the es8 and es6 suites.

Notes

• No production source is touched by this PR.
• The published softclient4es{N}-core-testkit artifacts change the minioContainer field type from MinIOContainer to MinioTestKit.S3MockContainer, which is binary-incompatible for an external subclass. Nothing in this repository or in softclient4es-jdbc, softclient4es-arrow or softclient4es-extensions subclasses it.
• Recorded in S3 test-fixture image minio/minio was deleted from Docker Hub — all four *CopyIntoS3Spec suites abort #323 and deliberately not changed here: dml_statements.md:370 documents the credential fallback as an AWS SDK v1 class name, which cannot load from this build's own classpath but remains functional for a consumer supplying the v1 SDK, since hadoop-aws is a provided dependency. Documentation-versus-implementation mismatch on a secondary path; the documented primary path works and is what these suites exercise.
• Pre-existing and untouched: uploadToMinio leaks a cached FileSystem if fs.create throws.

🤖 Generated with Claude Code