Enable AWS ENV VAR key auth

[ArangoGutierrez]

Before this PR, this project was only taking into account the region in the config file.
This PR fixes that by moving to (in descending order) :

• ENV AWS_REGION
• Config file

The aws config file is not taken into account by design. The idea is to be used by a GitHub action or manual testing.

[elezar]

Does this mechanism not work to set these options?

[ArangoGutierrez]

with that set, it default to config file first, then env vars.

[elezar]

I don't quite understand. There are three ways to set the AWS region here.

1. The config file as defined in this project.
2. The AWS config file.
3. The AWS_REGION environment variable.

In what order to we want to apply them? Why is the region special compared to other environment variables?

[ArangoGutierrez]

before this PR, this project was only taking into account the region in the config file.
This PR fixes that by moving to

• ENV AWS_REGION
• Config file
  aws config file is not taken into account, since the idea is to be used by a github action or manual testing.

[elezar]

Ok, but it isn't required to call os.Setenv("AWS_REGION") to do this? Would something like the following:

region := env.Spec.Region
if envRegion := os.Getenv("AWS_REGION"); envRegion != "" {
    region = envRegion
}
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion(region))

not be more explicit, and not assume that the os env is being read?

Note that if we take this further and resolve a "merged" spec where we load env.Spec from file, then we only ever need to pass around env.Spec.

[ArangoGutierrez]

Thanks for the suggestion, change added

[elezar]

Thanks @ArangoGutierrez

I think this looks good now. It may be good to consider how to handle envvars that override options in the config spec more generally at some point (like we do in the device plugin or GFD perhaps?), but that's not a blocker for this PR.