Make project and cluster secrets customs available in server

[jfreden]

This PR adds ClusterStateSecrets and ProjectSecrets (renamed to ClusterSecrets and ProjectSecrets).

The reason for moving these into core is to allow plugins to deserialize project and cluster secrets in cluster state as opposed to relying on reloadable plugin to do so. This enables features to read secrets from the same cluster state update as project creation.

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

Hi @jfreden, I've created a changelog YAML for you.

[ywangd]

I think this PR should be a non-issue since none of the classes is used in Stateful.

[ywangd]

Unfortunately this won't work for repository plugins since they do not have access to x-pack code and I don't think we want make them depend on it either. The classes will have to be part of the server package for broader access.

Also, I personally think it's fine to move these classes between repos. But it would be great to get confirmation from @tvernum since it incurs license changes.

[jfreden]

Good catch @ywangd ! I've moved them to server.

[ywangd]

LGTM with one minor comment

[ywangd]

There is also a ClusterStateSecretsMetadataTests file that can potentially be moved over as well.

[ywangd]

Nevermind. I just realized this is for a different class ClusterStateSecretsMetadata. It is a bit strange though that the secrets and the its metadata are now in separate repos.

[ywangd]

I guess you didn't move ClusterStateSecretsMetadata because it is something only the managing service cares about. Also, if we migrate cluster secrets to be managed by file setting service, the metadata class is no longer necessary since file setting service manages its own set of metadata.

[jfreden]

Thanks for raising this. Yes, that's what I was thinking. The reserved cluster state service will handle all that for us.