awsutil: ensure GenerateCredentialChain checks envs

[fairclothjm]

#57 caused a regression in Vault. In that PR the AWS environment variable checks in GenerateCredentialChain were moved to NewCredentialsConfig for AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE, and AWS_ROLE_SESSION_NAME. This caused users of the awsutil library that call GenerateCredentialConfig to fail to set the above values if they are depending on env variables to be read.

Another solution could be to find all users of go-secure-stdlib’s awsutil and ensure env vars are properly read and set in the config before calling GenerateCredentialConfig like in hashicorp/vault#21930. However, I think a this PR is a better resolution. With this change we shouldn't have to make any changes anywhere else.

This change was tested with the following steps:

• Create an AWS EKS cluster
• Connect the EKS cluster as an OIDC provider for AWS IAM
• Create an AWS KMS key
• Create an AWS IAM role with an assume-role policy authorizing that OIDC provider, and an inline policy authorizing that IAM role for actions on the KMS key you created
• Deploy Vault via Vault Helm version 0.24.1 with an "awskms" seal, setting only kms_key_id, and adding a ServiceAccount annotation eks.amazonaws.com/role-arn:
• Upgrade Vault via Vault Helm with a Vault image that includes this fix via go get github.com/hashicorp/go-secure-stdlib/awsutil@d18ccdf3e9fb

Additionally, this has been tested against the Boundary E2E tests by @ddebko. Thanks!

Closes #71

[swenson]

LGTM -- might be nice to add some unit tests though so we don't get another regression? This is a pretty long function with lots of edge cases.

[tomhjp]

LGTM, just one query

[fairclothjm]

might be nice to add some unit tests though so we don't get another regression? This is a pretty long function with lots of edge cases.

@swenson Agreed! I will address adding some tests in another PR if you are ok with that?