[Monitoring] Collect cluster.metadata.display_name

[pickypg]

Now that #33325 has been merged, Monitoring can collect the arbitrary cluster.metadata.* keys. Across Kibana and ES, we can agree to use specific keys to define added behavior that benefits both sides, such as cluster.metadata.display_name.

We can use that as a way to allow the user to override the cluster_name (e.g., if it was never set or it is set to something like a UUID) as described in elastic/kibana#23022. The easiest approach would be to explicitly grab that key and include it in the cluster_stats, or possibly include all of the cluster.metadata key/value pairs and simply have the UI pluck the one that is interesting.

[elasticmachine]

Pinging @elastic/es-core-infra

[jasontedor]

I think we should pull all the metadata keys, rather than a specific one that doesn't have meaning to Elasticsearch.

[pickypg]

I agree that they should grab all of them, but I'm not sure how that will play into what they want to do on the Metricbeat side of the fence, which will need to reproduce the behavior.

[ycombinator]

We can grab all of them and pass them through from within Metricbeat too (we do something similar with Kibana settings today).

Question: do we want to index these values or just store them in .monitoring-es-*? For the display_name use case storing should be sufficient, so I'm inclined to start with just storing for now.

[pickypg]

You won't be able to predictably index them without dynamic indexing, which can lead to collisions, so I do not suggest doing that. I would start with storing too.