Allow Auth credentials to be fetched via callback, backwards compatible

[JohnRbk]

This is an updated to an earlier PR that provides a backward compatible way for fetching auth tokens in a synchronous or asynchronous way.

Description of changes:

When using a CognitoUserPoolsAuthProvider or AWSOIDCAuthProvider, a client can create an auth provides that alternatively uses a callback:

class MyOIDCAuthProvider: AWSOIDCAuthProviderAsync {   
        func getLatestAuthToken(_ callback: @escaping (String) -> Void) {
            functionThatMakesNetworkCall(){ token in 
                callback(token)
            }
        }
    }

Using AWSCognitoUserPoolsAuthProvider instead:

class CognitoUserPoolsAuthProviderAsync: AWSCognitoUserPoolsAuthProvider, AWSOIDCAuthProviderAsync {
         func getLatestAuthToken(_ callback: @escaping (String) -> Void) {
            functionThatMakesNetworkCall(){ token in 
                callback(token)
            }
        }
}

See the AuthProviderTests.swift file for some examples. Also see this demo project which shows the OIDCToken generated via a network call.

In order to preserve backwards compatibility, the original AuthProvider classes were preserved and a new protocol was introduced AWSOIDCAuthProviderAsync which describes the callback required for classes to implement.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mutablealligator]

Great job! Just a few minor comments.

[mutablealligator]

remove extra blank lines

[mutablealligator]

What will happen if the token is empty? will the header be not set?

[mutablealligator]

seems like in async we only set header when token is not empty and we are setting header here irrespective of the token being empty or not.

[mutablealligator]

provide -> provider

[mutablealligator]

same 3 comments for OIDC applies here.

[mutablealligator]

2018 or 2018-2018

[mutablealligator]

remove blank line

[JohnRbk]

fixed

[mutablealligator]

Thank you @JohnRbk for submitting a new PR. I have given a few comments.

[JohnRbk]

@kvasukib great feedback. Thank you. After thinking about it, the use of a blank default string in the Async classes causes a silent error. Its not great, but a fatalError is probably a better solution.

I ran a few more tests and have pushed my latest commits for review.

[mutablealligator]

Great job! Thank you for addressing the comments! I have approved the changes. I'll wait on @rohandubal to give a final approval.

[rohandubal]

This is great! I only have one comment which I feel should be an important consideration(probably also a flaw with the sync pattern): We should have the signature of async function as (String?, Error?) -> Void rather than just (String) -> Void This would help the handler also pass in error object when the call fails and we can propagate it to the caller. Thoughts?

@JohnRbk will you have the bandwidth to make that change? If not, I might have to add some changes on top of these changes before we can draft a release. Thanks again for the PR!

[JohnRbk]

@rohandubal Please take a look at my updates and unit test. And yes, you're right that the sync callbacks should likely also have a similar way to propagate an error, but that could be a breaking change.

[rohandubal]

This is great! One thing which I am going to do though is add a separate user pools async auth provider to maintain separate auth providers for oidc vs userpools (even though it is duplication)