[filesystem] Support default AWS credential chain for S3 delegation

[fresh-borzoni]

Summary

resolves #3066

Currently the STS client in S3DelegationTokenProvider is hardcoded to use AWSStaticCredentialsProvider, so credential delegation only works when static access keys are in the config. This prevents using IRSA, instance profiles, or any other credential method from the default AWS chain. Additionally, S3FileSystemPlugin uses the presence of access.key to distinguish server from client, so a server without static keys is misdetected as a client and crashes with NoAwsCredentialsException.

This PR makes the STS client fall back to DefaultAWSCredentialsProviderChain when no static keys are configured, and requires roleArn in that case since GetSessionToken does not work with temporary credentials. The plugin now also treats roleArn presence as a server-mode indicator.

This is a targeted fix that does not change the delegation protocol or add new config keys.
The full credential delegation redesign (#2662) can build on top. See also #1245 which attempted a broader approach.

Tested E2E with LocalStack: Fluss server with env-var credentials (no static keys in config) + AssumeRole delegation, Flink client reading tiered log segments via delegated credentials.

[fresh-borzoni]

@affo @leekeiabstraction @luoyuxia @michaelkoepf
PTAL - targeted fix to enable IRSA support without the full redesign from #2662 🙏

[affo]

Thanks @fresh-borzoni!
I am going to have a full review tomorrow morning!

[Copilot]

Pull request overview

Enables S3 delegation token generation when the Fluss server authenticates via the AWS SDK default credential chain (e.g., IRSA/instance profile/env vars) rather than requiring static access keys, and fixes S3 plugin server/client mode detection to avoid misclassifying servers without static keys.

Changes:

• Update S3DelegationTokenProvider STS client construction to only use static credentials when configured, otherwise rely on the AWS default provider chain, and validate roleArn in that path.
• Update S3FileSystemPlugin to treat fs.s3a.assumed.role.arn presence as a server-mode indicator (in addition to static keys).
• Add unit tests for S3DelegationTokenProvider constructor validation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
fluss-filesystems/fluss-fs-s3/src/main/java/org/apache/fluss/fs/s3/token/S3DelegationTokenProvider.java	Makes STS client credentials provider conditional and adds validation for role-based delegation when static keys are absent.
fluss-filesystems/fluss-fs-s3/src/main/java/org/apache/fluss/fs/s3/S3FileSystemPlugin.java	Adjusts server/client detection to include roleArn and updates logging around credential provider selection.
fluss-filesystems/fluss-fs-s3/src/test/java/org/apache/fluss/fs/s3/token/S3DelegationTokenProviderTest.java	Adds tests for the new constructor validation behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[fresh-borzoni]

Addressed copilot's comments

[affo]

I really like this one, thank you @fresh-borzoni for the contribution!

I like this cleaner client/server detection separation and I like that you achieved a "partial" separation between server side credentials and delegated credentials, as you can now make the server authenticate using env vars (for example) and delegate via roles.

I think the missing part now would still be to be able to have 2 different roles, one for authenticating on the server side and one for delegating, or any possible collision on the server side. Let me rephrase: you can now split server access wrt delegation only if the credentials provider is "different". Which is already a big step ahead 🎉

Probably it is even more subtle, as I think you can differentiate only if the server authentication uses a credentials provider that comes sooner in the chain than the one you use for delegating 🤔 Correct me if I am wrong :)

Another missing part is the ability to disable the token delegation as a whole, but that's another story.

The only nit I have in mind: do we need to document this behavior? Probably better to add something to the S3 docs, maybe worth an example.