Fully populates aws.Config before calling resolveCredentials

[gdavison]

Setting the EC2IMDSClientEnableState to imds.ClientDisabled does not disable the EC2 IMDS Client when resolving configuration using config.LoadDefaultConfig().

Setting AWS_EC2_METADATA_DISABLED = true does correctly disable the EC2 IMDS Client.

The awsConfigResolver functions take the parameters (ctx context.Context, cfg *aws.Config, configs configs) where cfg has no ConfigSources set, and the config providers are passed in configs.

This works until the resolvers need to create a service client, such as imds.Client. The clients are created using their NewFromConfig function. The aws.Config with zero ConfigSources is then passed in, ignoring the config providers in configs.

This PR works, but doesn't make any deep changes. For instance, either of the following could be done:

1. Since resolveCredentials is no longer called in a loop with other awsConfigResolver functions, it doesn't need to match the interface, and could replace uses of config with the ConfigSources on the aws.Config
2. Change how the aws.Config is populated in the loop of awsConfigResolver functions. This could also allow the use of the ConfigSources on the aws.Config instead of the config parameter.

Closes #1398

[gdavison]

I'm not able to reproduce the test errors

[jasdel]

Thanks for taking the time to create this PR @gdavison. While reviewing the change I noticed the ConfigSources were being after before the config resolvers were being processed. This was incorrect. By moving assigning ConfigSources in resolveDefaultAWSConfig, it ensures the config sources are available for all downstream config resolvers, such as resolveCredentials. This also allows resolvedCredentials to stay in the set of resolvers, without being special cased.

[jasdel]

Not sure why unit tests are failing. I'm not able to reproduce that locally. They seem to only fail in GitHub actions.

[jasdel]

I think the reason the tests were failing in GitHub actions but not locally, must have something to do with environment. I updated the tests to use stub HTTP clients instead of real clients. This should prevent the issue.

[gdavison]

@jasdel One twist to this approach is that the subsequent awsConfigResolver functions no longer need the configs parameter, since the configs are now contained in the aws.Config. That was what I meant by my option 2 above

[jasdel]

Thanks for the feedback @gdavison. There is a subtle usage difference between ConfigSources in aws.Config and configs used by the resolvers. configs is the set of configuration providers the config resolvers will search through when initializing the SDK's generic aws.Config properties. Whereas ConfigSources was added later as a way to provide API client with lazy configuration data without exposing API client specific fields in aws.Config directly.

These two values do overlap currently, but the intention is that ConfigSources could be appended with additional configuration sources by resolvers to be used by API clients. Whereas the set configs are only intended to be the initial set of configuration providers such as shared config, environment variables, and LoadOptions.

SharedConfig, EnvConfig, and LoadOptions play double duty as both config providers when resolving configuration, and lazy configuration sources for API clients.