[David-Banquet]

Closes #2747

Rationale for this change

This picks up #3838 by @lemon0333, which was closed for inactivity before anyone reviewed it (see my comment there). Their commit is kept as is, with them as author.

client.role-arn / client.role-session-name are honored by the S3 FileIO but ignored by the Glue and DynamoDB catalogs, which build their own boto3.Session. #3838 extends them to both catalogs, with service-prefixed overrides (glue.role-arn, dynamodb.role-arn, and the matching *-role-session-name) falling back to the client.* ones, like the other session properties.

The second commit changes one thing: #3838 built the catalog session from the static credentials of a single AssumeRole call, so a long-lived catalog started failing with ExpiredToken once the role session ended (one hour by default). The session now uses botocore's AssumeRoleCredentialFetcher with DeferredRefreshableCredentials: the role is assumed on first use and again before the credentials expire, the same way botocore handles role_arn in an AWS profile.

Are these changes tested?

Yes, with moto:

• the 7 tests from Support assume-role for Glue and DynamoDB catalogs #3838 (unified and prefixed properties, no assume-role without an ARN, temporary credentials);
• a new test that advances the clock into botocore's refresh window and checks that the Glue catalog assumes the role again. It fails on the Support assume-role for Glue and DynamoDB catalogs #3838 version.

uv run python -m pytest tests/catalog/test_glue.py tests/catalog/test_dynamodb.py
# 99 passed
uv run prek run --files <changed files>
# all passed

Are there any user-facing changes?

Yes: the Glue and DynamoDB catalogs now honor client.role-arn / client.role-session-name, plus the new glue.role-arn, glue.role-session-name, dynamodb.role-arn and dynamodb.role-session-name. Documented in configuration.md. Nothing changes when no role ARN is set.

🤖 Generated with Claude Code

[Fokko]

Thanks for adding this @David-Banquet I've left a small comment

[Fokko]

The order is different here. Can we first do arn, and then role-session-name?

I've checked against the Java implementation, and there we use client.assume-role.arn and client.assume-role.session-name. Can we use the same keys here? This way when this information is supplied through a catalog, then it works for both.

[David-Banquet]

Thanks, done in ccd5aaa. The table now lists client.assume-role.arn first, then client.assume-role.session-name.

client.role-arn and client.role-session-name already existed for the S3 FileIO, with s3.role-arn / s3.role-session-name as overrides, so I kept them as a fallback. The catalogs and the S3 FileIO now read client.assume-role.* first, then client.role-*. A catalog that passes the Java keys covers both, and existing configs keep working. The glue.role-* and dynamodb.role-* overrides follow the s3.role-* pattern.

Should the client.role-* keys also get a deprecation warning, or stay as aliases?