Support assume-role for Glue and DynamoDB catalogs

[lemon0333]

Closes #2747

Rationale for this change

At the moment, assume-role (client.role-arn / client.role-session-name, via STS) is only honored by the S3 FileIO (pyiceberg/io/pyarrow.py). The AWS catalogs (Glue, DynamoDB) build their own boto3.Session and ignore these properties, so users who authenticate to AWS by assuming a role cannot use it to reach the catalog — even though the other client.* properties (region, access key, etc.) are already shared between S3 FileIO and the catalogs.

This PR extends the same assume-role behavior to the GlueCatalog and DynamoDbCatalog boto3 sessions:

• A small shared helper _get_aws_session_with_assumed_role() (in pyiceberg/catalog/__init__.py) performs the STS AssumeRole from the base session and returns a new session using the returned temporary credentials.
• Each catalog resolves the role config with the same precedence already used for the other client.* properties: a service-prefixed override falls back to the unified property:
  • glue.role-arn / dynamodb.role-arn → client.role-arn
  • glue.role-session-name / dynamodb.role-session-name → client.role-session-name
• When no role ARN is configured, behavior is unchanged.

I've kept the new service-prefixed property names consistent with the existing glue.* / dynamodb.* → client.* convention, but I'm happy to adjust the naming (e.g. unified-only) to match maintainer preference — feedback welcome.

Are these changes tested?

Yes. New moto-based tests (mock STS + Glue + DynamoDB) in tests/catalog/test_glue.py and tests/catalog/test_dynamodb.py cover:

• assume-role is triggered via the unified client.role-arn / client.role-session-name;
• service-prefixed properties (glue.role-arn / dynamodb.role-arn) take precedence over the unified ones;
• no assume-role call is made when no role ARN is set (default behavior unchanged);
• the helper returns a session backed by temporary STS credentials (session token present).

uv run python -m pytest tests/catalog/test_glue.py tests/catalog/test_dynamodb.py -k "role or assume or session_properties"
# 11 passed

uv run python -m pytest tests/catalog/test_glue.py tests/catalog/test_dynamodb.py
# 98 passed

uv run prek run --files pyiceberg/catalog/__init__.py pyiceberg/catalog/glue.py pyiceberg/catalog/dynamodb.py \
  tests/catalog/test_glue.py tests/catalog/test_dynamodb.py
# ruff / ruff-format / mypy / pydocstyle / codespell: all Passed

Are there any user-facing changes?

Yes — new opt-in configuration properties for assuming an IAM role when connecting to the Glue/DynamoDB catalogs: client.role-arn / client.role-session-name (now honored by the catalogs too), plus service-specific glue.role-arn / glue.role-session-name and dynamodb.role-arn / dynamodb.role-session-name. Documented in mkdocs/docs/configuration.md. No change to default behavior.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that's incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

[David-Banquet]

@lemon0333 I'd like to see this land, so I rebased it on today's main to check where it stands: it applies cleanly and tests/catalog/test_glue.py + test_dynamodb.py pass (98 tests, including your 7 role tests), ruff is clean.

One thing I'd raise before a maintainer review: _get_aws_session_with_assumed_role builds the session from the static credentials of a single AssumeRole call, so session.get_credentials() is a plain Credentials with no refresh. A long-lived process (a service holding a GlueCatalog) starts getting ExpiredToken once the role session ends, one hour by default. The S3 FileIO does not have this problem as far as I can tell, since it hands the ARN to Arrow, which refreshes through the SDK's STS provider. botocore can do the same here with AssumeRoleCredentialFetcher + DeferredRefreshableCredentials.

Do you want to reopen this and carry on? If you don't have time for it anymore, I'm happy to open a new PR from your commit with the refresh added, keeping you as co-author.