feat: AWS KMS Keyring(s) refactor/reimplementation

[acioc]

Issue #, if available:

• implementation: re-designing the AWS KMS keyring #199

Description of changes:

• Re-implementing the AWS KMS keyring(s)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

• Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.
  Files were moved but links (internal to this codebase) have been updated accordingly. Files prior to keyrings have not been moved.

[lavaleri]

Review Part 1 up to AwsKmsSymmetricRegionDiscoveryKeyring.java

[lavaleri]

Finished Part 2 of naive review. I will take another pass tomorrow looking closely at https://github.com/awslabs/aws-encryption-sdk-specification/blob/master/proposals/2020-07-01_aws-kms-keyring-redesign/change.md and ensuring we have sufficient test coverage over the spec of that behavior.

[lavaleri]

Good work! LGTM once feedback is resolved one way or another. Feel free to let me know if any of this feedback should be addressed as part of #223 instead.

[lavaleri]

Taking another look at this, the example makes sense, but I still think will be confusing for customers. At the very least "CustomDataKeyEncryptionDao" as an example name isn't very helpful because customers don't know what a DataKeyEncryptionDao is. Maybe this would be better framed as a "CustomCredentialProvider" example? And then explain what the default credential provider configuration is.

It might also be good to highlight the difference between this example and the CustomKmsClientConfig example. That example is useful if you want every call using the same client config. If you need different client config depending on the key you're trying ot decrypt (in this example, based on what region it is), then you'll need to do something more complicated, like in this example.