Support scoped AWS configurations

[omus]

Addresses part of: #717.

Deprecates global_aws_config in favor of using with_aws_config for scoped setting of an AWS configuration and current_aws_config for accessing. The new with_aws_config is thread safe unlike the old global_aws_config. What this doesn't do is eliminate the ability to set the AWS configuration on a per-API call basis which is the controversial bit of #717.

Reviewers note: The changes in src/services/* just change global_aws_config() to current_aws_config().

Supersedes #718 which the GitHub UI is having a hard time with due to the numerous formatting suggestions which were made on that PR.

TODO:

• Remove existing calls to global_aws_config
• Add tests
• Update documentation

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1211537285715619
  • https://app.asana.com/0/0/1210499982586983
  • https://app.asana.com/0/0/1210547384307413

[kleinschmidt]

I'm in favor of the support for with_aws_config and scoped values. I'm not so sure about deprecating and eventually removing global_aws_config. On the "pro" side, I think that removing it will encourage better practices around e.g. setting any global configuration via environment variables outside of code or using the scoped values. On the "con" side, I strongly suspect that for script usage, people will "learn" to do something like ENV["AWS_PROFILE"] = "my-local-profile-hehe" rather than constructing a config from a role directly. Unless we're willing to go all the way and totally remove the global fallback option, it seems a net loss to me to remove the ability of users to set that global/fallback. Forcing folks to put their actual code in a function body (either anonymous do block or otherwise) is juuust annoying enough that I can see people being inclined to work around it by setting the global fallback in some other way, which I don't think is really the goal of this PR.

[kleinschmidt]

add a method that passes kwargs to AwsConfig like global_aws_config does?

Suggested change

	function with_aws_config(f, config::AbstractAWSConfig)
	return @with _SCOPED_AWS_CONFIG => config begin
	f()
	end
	end
	function with_aws_config(f, config::AbstractAWSConfig)
	return @with _SCOPED_AWS_CONFIG => config begin
	f()
	end
	end
	with_aws_config(f; kwargs...) = with_aws_config(f, AwsConfig(; kwargs...))

[omus]

I'm opposed to this as I think constructing an AWSConfig to pass in isn't much more to write and deprecating the kwarg version of global_aws_config was a pain. Additionally, this makes alternate AbstractAWSConfig implementations feel less like second class citizens.

[omus]

I'm in favor of the support for with_aws_config and scoped values. I'm not so sure about deprecating and eventually removing global_aws_config. On the "pro" side, I think that removing it will encourage better practices around e.g. setting any global configuration via environment variables outside of code or using the scoped values. On the "con" side, I strongly suspect that for script usage, people will "learn" to do something like ENV["AWS_PROFILE"] = "my-local-profile-hehe" rather than constructing a config from a role directly. Unless we're willing to go all the way and totally remove the global fallback option, it seems a net loss to me to remove the ability of users to set that global/fallback. Forcing folks to put their actual code in a function body (either anonymous do block or otherwise) is juuust annoying enough that I can see people being inclined to work around it by setting the global fallback in some other way, which I don't think is really the goal of this PR.

Hmmm, I don't love the global fallback myself and I ended up adding it for two reasons:

1. I needed a way to make this change non-breaking
2. I wanted a way to cache an AWS config when working outside of the scope of a with_aws_config

Maybe the half-step to do at this point is to not deprecate global_aws_config fully but rather use that as the default and have scoped AWS configurations in addition. I'll give that a spin.

[omus]

I'll push an implementation tomorrow but the plan at this moment is to:

• Remove the deprecation for global_aws_config(::AbstractAWSConfig) for setting the AWS configuration when outside of all with_aws_config scopes.
• Continue deprecating global_aws_config() as we need to have users switch to using current_aws_config() for retrieving the AWS configuration for the current scope or the global configuration. In the future we may want to use this again to be able to determine the config set via global_aws_config(::AbstractAWSConfig).
• Continue deprecating global_aws_config(; kwargs...). I think global_aws_config(AWSConfig(; kwargs...)) isn't overly verbose. Once again this avoids making all other AWS configuration types from looking like second class citizens.

[omus]

I ended up using the name default_aws_config instead of global_aws_config as it made the deprecation simpler, informed the user something had changed, and allowed me to change the return type for default_aws_config(::AbstractAWSConfig) to be Nothing.

[kleinschmidt]

I'm good with this deprecation pathway. Just a few typos/doc improvements to suggest, but you can take or leave them.