KMSKeyring error handling

[seebees]

The multi keyring will "notify" an error if a child keyring errors
and no other child keyring is able to decrypt and encrypted data key.

The KMSKeyring should do the same thing,
even if it is in discovery mode.

See: aws/aws-encryption-sdk-javascript#212

Currently the C ESDK does not "notify" the errors if in discovery mode.

[mattsb42-aws]

IMO this is two questions:

1. When is a keyring permitted or required to stop encrypt/decrypt operations?
2. If a keyring encounters an error state that does not force it to stop operations, how does it communicate that to the caller?

For the first question, I would argue that:

• During encryption, if a keyring cannot satisfy its decryption contract, that keyring MUST stop the ESDK encryption process.
• During decryption, no keyring is permitted to stop the ESDK decryption process.

The reason for this is explored here[1] for the AWS KMS keyring, and we need to generalize that to the keyring interface.

[1] https://github.com/awslabs/aws-encryption-sdk-specification/blob/9cd6a59db75ff0e0829a661e0a04878b1f96b01e/framework/kms-keyring.md#configuration-intent

[juneb]

What is a "decryption contract?" I don't see that term used or defined in this specification.

[mattsb42-aws]

That's a good call out. "Decryption contract" is the shorthand I've started using to refer to the properties that a caller is stating MUST be true through details of the keyring configuration[1]. I described it in the AWS KMS keyring spec because we had a pressing need, but we need to generalize this concept into the spec somewhere because this is a more general characteristic that all keyrings need to consider.

[1] https://github.com/awslabs/aws-encryption-sdk-specification/blob/9cd6a59db75ff0e0829a661e0a04878b1f96b01e/framework/kms-keyring.md#onencrypt-goal

[acioc]

Closing in favor of #165