[fs] Support IRSA with AssumeRole delegation tokens

[fresh-borzoni]

Fluss 1.0.0 has no working configuration for EKS IRSA.

Hadoop S3A's default provider chain has no web-identity entry. On 3.4.3 STANDARD_AWS_PROVIDERS is:
EnvironmentVariableCredentialsProvider
IAMInstanceCredentialsProvider
SimpleAWSCredentialsProvider
TemporaryAWSCredentialsProvider

So the setup our docs currently recommend for EKS: omit the keys, let the default chain authenticate silently runs the server's own S3 access on the EC2 node role instead of IRSA. Delegation tokens still work, because that path falls back to the SDK's own chain, which does include web identity.

Fixing it means naming the provider explicitly and it's not working
Setting a provider alongside s3.assumed.role.arn is rejected outright. Dropping the role ARN doesn't help either as provider mode mints client credentials with GetSessionToken, which cannot be called with temporary credentials, so IRSA is refused there too.

The two settings aren't actually in conflict. AssumeRole accepts a caller holding temporary credentials, so the provider can serve the server's own S3 access while the role mints credentials for clients.

The way through is to set the provider per bucket instead of globally:

fs.s3a.bucket.<bucket>.aws.credentials.provider: software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider
fs.s3a.assumed.role.arn: <delegation-role-arn>

That passes because the check inspects three exact global keys, and S3A's propagateBucketOptions promotes the bucket-scoped key to fs.s3a.aws.credentials.provider during S3AFileSystem.initialize, after the check has run. The data path ends up on IRSA and delegation tokens stay on AssumeRole. But it's brittle tbh