fix: update env provider to skip terminal resolver registration if asume role creds are configured

[arandito]

Description

The EnvironmentCredentialsProvider previously registered a terminal resolver whenever AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY were present in the environment. This short-circuited the credential chain even when the active profile was configured to assume a role using those environment credentials as the source, meaning the source credentials were handed back directly instead of being used to make the AssumeRole call.

This change makes the provider skip registering a terminal EnvironmentCredentialsResolver when a profile is explicitly configure in IdentityChain.create() and that profile declares both role_arn and credential_source = Environment, deferring to assume-role resolution.

Example profile that triggers the skip (~/.aws/config):

[profile assume]
role_arn = arn:aws:iam::123456789012:role/example
credential_source = Environment

With this profile, the environment credentials are treated as the source for the AssumeRole call rather than the credentials to return.

Testing

• Added unit tests in test_environment.py:
• Ran make test-py- 1881 passed, 9 skipped.
• Ran make check-py - ruff, format, and pyright all clean.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jonathan343]

We aren't caching the config here which means we'll end up doing duplicate work. We need to ensure that we're always only reading the config file only once. Let's also keep this in mind when we integrate with @ubaskota's config resolver work.

Also, might want to make this a method on setup or some other class so we can just reuse loading caching logic.

[jonathan343]

I'm just now realizing that when a customer attempts to use the assume role provider and doesn't install aws-credentials-sts, they don't get a helpful error message. They just get:

smithy_aws_core.identity.chain.exceptions.IdentityChainError: No credential providers were configured to resolve an identity.

Not sure if this is another gap in the SEP or a miss on our end. Can you look into this?