feat: Add S3 External Storage Driver (Claim Check pattern)

[brucearctor]

Summary

Implements the S3 External Storage Driver for the Java SDK, as described in #2882 and the cross-SDK feature spec temporalio/features#783. This ports the Claim Check pattern already implemented in the Go and Python SDKs.

Problem

Temporal has a payload size limit (~2 MiB). Workflows dealing with large data (ML models, documents, media) hit this limit.

Solution

External Storage adds a transparent stage to the data converter pipeline that automatically offloads large payloads to S3 and replaces them with lightweight claim tokens in Event History.

Wire Format (Cross-SDK Compatible)

Claim token payloads use encoding temporal-external-storage/claim with claim data stored as prefixed metadata entries (claim.*). Compatible with Go and Python SDK implementations.

Changes

New Module: temporal-s3-external-storage

• S3StorageDriver — StorageDriver impl with content-addressed storage (SHA-256)
• S3StorageDriverOptions — Builder-based config (bucket, key prefix, driver name)
• S3Client / AwsSdkV2S3Client — Abstracted S3 client for testability

Core SDK (temporal-sdk)

• StorageDriver interface — SPI for storage backends
• ExternalStorage — Config (threshold, driver selection)
• CodecDataConverter — Integration as terminal pipeline stage
• WorkflowClientOptions.setExternalStorage() — Auto-wires into data converter

Usage

S3StorageDriver driver = new S3StorageDriver(
    S3StorageDriverOptions.newBuilder()
        .setClient(new AwsSdkV2S3Client(awsS3Client))
        .setBucket("my-temporal-payloads")
        .build());

WorkflowClientOptions options = WorkflowClientOptions.newBuilder()
    .setExternalStorage(ExternalStorage.newBuilder().addDriver(driver).build())
    .build();
// Payloads > 256 KiB are now automatically offloaded to S3

Security

• Path injection prevention: URL-encoded path segments in S3 keys
• Confused deputy prevention: retrieve() ignores bucket from claim data
• Metadata key collision prevention: claim data keys prefixed with claim.

Testing

• 21 tests total (15 core + 6 S3 driver)
• Full pipeline integration test
• Java 8 compatible

Closes #2882

[jmaeagle99]

Thanks for making this contribution. There is an existing PR (#2907) for contributing an S3 driver in Java. I think that it is best to continue to provide feedback there and merge that PR when it is ready.

[brucearctor]

@jmaeagle99 -- any reason the PR wasn't linked to the issue?

It is disappointing to devote time to address open issues -- seeing nobody assigned and no PR attached and thinking that is useful time to help the project. Then to be notified, there is unlinked work in process and that was time not well spent.

Ultimately, that is discouraging and creates a higher bar for me to be contributing if i need to check around for open PRs that are not linked and when nobody is assigned?

Any thoughts on how to assuage that concern? Is there a community expectation that PRs would be linked? That if someone is working on something they would be assigned? Ex: what is the community expectation [ ex: that I need to check for PRs that are not linked to open issues ]??

Generally, I look around for issues not assigned and not having associated PRs. Otherwise, what's the reccommended process for how to go ahead and figure out where to contribute? Is it expected I wait and ask and hope for a response before working on a contribution [ I suspect that's added friction, which doesn't help many ]?