test(sts): refactor AssumeRole integration test to role-based credentials

[joviegas]

Motivation and Context

The STS AssumeRole integration test created an IAM user and a long-term access
key on every run. This replaces that with an IAM role assumed by the identity the
test already runs as, so no static access key is created.

Modifications

• Removed IAM user, managed policy, and access key creation from the integration
  test. It now sources the assume-role chain from the test's own credentials and
  creates only a temporary role that trusts the running identity.
• Kept all three integration test cases with unchanged profiles, provider wiring,
  and assertions. The source credentials now carry a session token.
• Moved the one no-session-token resolution case (previously only covered by the
  integration test) to a unit test in AssumeRoleProfileTest.

Testing

• Junit and Integ tests

Screenshots (if appropriate)

License

• I confirm that this pull request can be released under the Apache 2 license

[alextwoods]

nit: I know some of this is pre-existing, but I think in theory we shouldn't trash these properties (ie, we should restore them to what they were before the test). Not sure, but EnvironmentVariableHelper might help?

[joviegas]

EnvironmentVariableHelper only handles environment variables, so it can't help with system properties. I'm also not sure restoring the previous value helps in practice: any test that depends on these properties sets them explicitly in its own scope rather than relying on values left behind by another test.

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.