Cluster: Add the option to set a memberlist label for the cluster

[JohnnyQQQQ]

This PR adds the option to set the Memberlist label for the created cluster. This can be important if multiple clusters are run i.e. on Kubernetes, and IPs get recycled. Some more context from this blogpost:

Why memberlist labels matter
We would be doing our community a disservice if we didn’t mention the importance of using labels when using embedded memberlist.

In Grafana Cloud, for the sake of simplicity (and in order to run as few open ports as we can), Mimir/Tempo/Loki all run memberlist using the same service name, Kubernetes label, and port. Mostly.

Because of the way Kubernetes works, it is possible for it to reassign the same IP address to pods in different namespaces when pods stop/start. When using the same Kubernetes service name and port, this can result in a pod within a Loki namespace communicating with a pod in the Mimir namespace whose IP previously belonged to a Loki pod within Loki’s ring. This problem can be mitigated with the use of labels in memberlist, ensuring that cross namespace memberlist communication is rejected by the processes running memberlist themselves.

Once you add labels to memberlist gossip messages, each component in a namespace’s ring will not accept messages that don’t have the required label. We set this label config value to k8s cluster.k8s namespace to ensure it is unique across clusters and namespaces.

If you are migrating to memberlist from an existing KV store, you can simply add the configuration to set your memberlist label in step 1 of the earlier migration steps. However, if you are already running memberlist and plan to deploy another Loki instance (or any other database) in the same IP address space you should migrate your existing deployment to use labels.

[gotjosh]

Shall we upstream this directly? Then we can just sync the fork pretty quickly.