IRSA credentials preferred over explicit STS session in environment variables

[md5]

Describe the bug
When both AWS_ROLE_ARN/AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN are set, this library is preferring the former. This causes Vault 1.4.0+ to ignore an explicitly set access key in the environment in favor of IRSA. This seems like a bug to me. If someone has gone to the trouble of exporting the access key and session token variables from an STS session, it doesn't make sense to request new credentials with IRSA. Presumably if a user has done this, they have already used the IRSA-based credentials to call sts:AssumeRole.

To Reproduce
Steps to reproduce the behavior:

1. In a Kubernetes pod with IRSA enabled, run aws sts assume-role to assume an STS role in another account
2. Export the access key ID, secret, and session token as AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN
3. Run vault login -method=aws role=some-vault-role
4. Receive error looking up full ARN of entity error

Having this be a cross-account scenario is key to getting the error looking up full ARN of entity error specifically, but if it isn't a cross-account role you would likely just get a failed login when the role ARN from IRSA does not match the bound ARN wildcards.

Expected behavior
When AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set in the environment (and optionally AWS_SESSION_TOKEN), awsutil should ignore AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE. This is how aws sts get-caller-identity works, for example.