Publish S3 dataset cache files atomically

[tlwillke]

Summary

Fix a shared-cache race in the benchmark dataset loader's S3 download path.

Currently, S3 downloads write directly to the final cache filename. ensureFileAvailable accepts an existing path as a cache hit, so another process can use a partially downloaded file. A killed process can leave that partial file at the cache name. Failed attempts also delete the shared destination, potentially removing another process's completed download.

Each S3 attempt now downloads to a unique temporary file in the destination directory. After completion and the existing content-length check, it atomically renames that file to the cache path. Failures delete only their own temporary file. HTTP already uses atomic publication and is unchanged.

This is based on current main 056d93c2. It changes the examples dataset loader only.

Validation

• Added deterministic tests with controlled S3 transport, exercising the real cache, retry, validation and publication code without an external service.
• On unmodified main, the partial-file visibility and concurrent-cache-hit tests fail.
• With this fix, tests verify that partial files remain unpublished, a failed concurrent attempt cannot delete a successful publication, and invalid-length retries clean up their private files.
• Maven loader suite: 75 tests passed (72 existing + 3 new).

mvn -Pjdk20 -pl jvector-examples -am \
  -Dtest=DataSetLoaderSimpleMFDTest,TestDatasetDownloadPublication \
  -Dsurefire.failIfNoSpecifiedTests=false test

Limits

Concurrent callers may still download the same object independently; publication is atomic rather than serialized by a new locking mechanism. Hard termination may leave an ignored temporary file. Existing cached files are not retroactively validated, so previously interrupted downloads should be removed before reuse.

A bug-fix release note is included.

[github-actions]

Before you submit for review:

• Does your PR follow guidelines from CONTRIBUTIONS.md?
• Did you summarize what this PR does clearly and concisely?
• Did you include performance data for changes which may be performance impacting?
• Did you include useful docs for any user-facing changes or features?
• Did you include useful javadocs for developer oriented changes, explaining new concepts or key changes?
• Did you rebase your branch onto the latest main for regression testing and PR submission?
• Did you trigger regression testing via Run Bench Main and review results?
• Did you adhere to the code formatting guidelines (TBD)
• Did you group your changes for easy review, providing meaningful descriptions for each commit?
• Did you ensure that all files contain the correct copyright header?
• Did you add documentation for this feature to the release notes directory?

If you did not complete any of these, then please explain below.

[MarkWolters]

I think this looks fine. I'll mention that compaction also has its own s3 download path in CompactionPartitionSource that this does not touch and it would be good in the future to deduplicate that cc: @dian-lun-lin

[ashkrisk]

PR looks good. There were no issues having two runs of BenchYAML running simultaneously and trying to download the same dataset. This would occupy extra disk space for as long as the BenchYAML processes are running, but that doesn't seem like a big concern given our typical usage patterns.