Epic: configured CryptoProvider enhancements/hardening

[jakedoublev]

Background

At present, the server.cryptoProvider in the platform config is used primarily for management of KAS keys. However, the platform engages with other sensitive cryptographic and crypto-adjacent materials (keys of varied types for other services, tokens, TLS certs, HSM information, etc).

Rather than spreading configuration of varying crypto-related values across the service configs, we should enhance and centralize the cryptoProvider config interface to make it extensible to n number of keys and key types across n number of services, and let each service do its own validation/panic that it has the cryptographic material it requires.

Centralizing sensitive config will make administration of a platform and development on top of it both easier.

Acceptance Criteria

TODO

[jrschumacher]

@dmihalcik-virtru Jake and I were discussing how an admin would manage the cryptoprovider when we look at supporting clickops. Currently, they would have to update the config or update the Envs.

Do you have any thoughts about this you'd like to add?

[jakedoublev]

Related to #1254

[jrschumacher]

@jakedoublev @strantalis @dmihalcik-virtru let's collaborate on this. We're seeing a number of areas where we need key material apart from KAS. It seems that cryptoprovider needs to be part of the core to support the various usecases.

[jakedoublev]

@jrschumacher It looks like @dmihalcik-virtru did some work around this in the past few weeks: #1834

[dmihalcik-virtru]

yes, I have a modified version of the cryptoprovider config in the branch that is referenced above. I'm putting it on hold until after Sean's work with the new key table and my work with ECC for TDF land