Introduce AddCredentialsFactory() extension methods

[chase-miller]

Description

This PR updates the AWSSDK.Extensions.NETCore.Setup nuget package with the following:

• Introduces IServiceCollection.[Try]AddCredentialsFactory extension methods
• Provides a DefaultAWSCredentialsFactory that is effectively a move of the private ClientFactory.CreateCredentials method
• Updates the ClientFactory to use the injected IAWSCredentialsFactory
• Adds a registration for AWSCredentials so that it can be injected by consuming code.

Motivation and Context

There are scenarios where it's necessary to obtain AWSCredentials. One scenario is adding sigv4 headers when making RESTful calls using the idiomatic HttpClient; as an aside I happen to be using the AwsSignatureVersion4 nuget package for this. Today a consumer has to effectively copy the ClientFactory.CreateCredentials method to be able to register an AWSCredentials object that is created in a way that leverages AWSOptions. With these changes a consumer simply needs to call services.AddCredentialsFactory() and then inject AWSOptions where needed.

These updates also provide a hook for a consumer to customize the way in which AWSCredentials are provided to ServiceClients.

Testing

I added 10 unit tests to the DependencyInjectionTests. I'm also using what is effectively a fork with these changes in production code.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [?] My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[dscpinheiro]

Is there an existing issue with more details on the problem you're trying to solve?

We made significant changes to both the AWSSDK.Extensions.NETCore.Setup package and credential resolution in our upcoming V4 version (#3362) and I'm afraid a lot of the work you've done cannot be reviewed as is.

[chase-miller]

Is there an existing issue with more details on the problem you're trying to solve?

Nope I haven't created an issue, but I'd be happy to do so. What additional detail are you looking for? Maybe code samples?

We made significant changes to both the AWSSDK.Extensions.NETCore.Setup package and credential resolution in our upcoming V4 version (#3362) and I'm afraid a lot of the work you've done cannot be reviewed as is.

How should it change so that it can be reviewed?

[chase-miller]

P.S. Would it be better if I opened a PR that targets a v4 branch? I looked at the v4-release branch, and it appears that these changes could be applied against that version of the lib. I think the problem I'm trying to solve for remains in v4 (ClientFactory still uses a private method to resolve credentials), but I only spent a couple minutes looking at the code.

[chase-miller]

@dscpinheiro FYI that I just created issue #3716 to provide additional context. Let me know if it makes sense to implement these changes against the v4-development branch.

[chase-miller]

@dscpinheiro bump :-)

[normj]

The feature of having an opt-in mechanism on AWSSDK.Extensions.NETCore.Setup that adds AWSCredentials to the dependency injection container makes sense to me. We do need to retarget this PR to v4-development. V4 is close to being GA and at this point any new features should be first done in V4 and then we can debate about back porting to V3.

A question I have is should we injecting AWSCredentials instead of a IAWSCredentialsFactory since that is what is likely going to to be used on other service's constructor. There could also be registered the IAWSCredentialsFactory and then the service register for AWSCredentials would grab the IAWSCredentialsFactory and use that. And the register method would be AddAWSCredentials instead of AddCredentialsFactory. I'm just not sure how many users will not what the factory is and that would appear more of an implementation detail to get to what users want which is the credentials.

[chase-miller]

@normj I created a series of draft PRs that target v4-development and build off one another. Really just trying to throw out ideas...

1. Add a CredentialsFactory prop to AWSOptions chase-miller/aws-sdk-net#1
2. Register IAWSOptionsFactory via DI chase-miller/aws-sdk-net#2
3. Make AWSOptions a dto chase-miller/aws-sdk-net#3
4. Expose [Try]AddAWSCredentials extension methods chase-miller/aws-sdk-net#4
5. Remove IAWSCredentialsFactory in favor of DefaultAWSCredentials chase-miller/aws-sdk-net#6
6. Break apart ClientFactory into DI-registerable pieces chase-miller/aws-sdk-net#7

I would probably only do 3+. The 6th in that list is a can of worms, but I figured I'd share it as imo it offers a lot of flexibility to the consumer; it might be advantageous to split ServiceCollectionExtensions like in 6 regardless since it's getting pretty big.

A question I have is should we injecting AWSCredentials instead of a IAWSCredentialsFactory since that is what is likely going to to be used on other service's constructor. There could also be registered the IAWSCredentialsFactory and then the service register for AWSCredentials would grab the IAWSCredentialsFactory and use that. And the register method would be AddAWSCredentials instead of AddCredentialsFactory.

I (think I) implemented this in the 5th PR in the list above. Does that align with what you're thinking? This seems cleaner to me than creating another type but I haven't tested.

I created #3758 for 5 that targets the v2-development branch directly in case that's simplest for you.

I'm just not sure how many users will not what the factory is and that would appear more of an implementation detail to get to what users want which is the credentials.

I'm with you there. It also gets a little awkward with AWSOptions exposing its Credentialsproperty. What if I set this property and call AddAWSCredentials()...which one wins?

Note that I ran across an issue with registering AWSCredentials as anything but a singleton, so we might want to add a warning or something in the code's xml docs. We could lock it down so that AWSCredentials must be a singleton, but that seems too restrictive. The issue was that some AWSCredentials implementations implement IDisposable, so the DI framework was disposing the object after use. FallbackCredentialsFactory was then trying to reuse a cached instance of the object (and we'd get object disposed exceptions).

Thoughts on any of these iterations?