better handling of masterEncryptionKey change

[joel-bluedata]

Currently if the masterEncryptionKey in kd-global-config is changed (or kd-global-config is deleted), the following things are true:

• Any newly specified secret key value will be properly encrypted.
• Any existing value will still be readable within the container as long as nothing triggers a configmeta update.
• Any existing value will get scrambled within the container when configmeta update happens. (Unless a change in master key length actually now causes any configmeta update to error out, which is even worse.)

The first of those is fine and good. The second is probably good/expected too. The third is not. And the third isn't easy to catch/fix in the validator because we no longer have either the original value or the original master key accessible to KD (at least, not easily).

Another consideration here: why would someone WANT to change the master key? The only reason that immediately presents itself is that someone-who-shouldn't got a look at the master key and therefore they would be able to decrypt the encryptedKey values in the existing kdcluster specs. Well, even if you change the master key, those encryptedKey values will not automatically be changed, so they would still be vulnerable to anyone who stole the old master key.

Let's discuss the desired behavior, and if there's any low-hanging-fruit improvement we need to make before the 0.7.0 release.

My thought about immediate changes:

Failure to decrypt an encryptedValue should just remove the associated value from the configmeta, rather than failing the configmeta generation.

Possibly we should block changes to masterEncryptionKey -- including kdconfig deletion -- while kdclusters exist. (This would be quick to do, just check if shared.clustersUsingApp has any content.) This is super annoying since the only valid reason to change masterEncryptionKey occurs when some kdclusters exist ... however as mentioned above, we don't yet properly handle that situation anyway.

[joel-bluedata]

Examples of those "immediate changes" added to PR #513.

[joel-bluedata]

Merged a few immediate changes/fixes:

• No changing the master key while kdclusters exist.
• No deleting kdconfig while kdclusters exist (because basically this changes the master key).
• If a secret-key value fails to decrypt, just omit it from configmeta rather than failing all configmeta generation.

Now we need to decide how we can support changing the master key.