Implement cilium clustermesh connect using new Helm functions

[asauber]

The cilium clustermesh connect subcommand is the final subcommand in the Cilium CLI which templates and creates Kubernetes resources outside the context of Helm.

It has a significant amount of autoconfiguration logic, such as determining the public IP addresses of the clustermesh-apiserver for each cluster, which we want to maintain.

However, there are aspects of this autoconfiguration which need significant improvement, for example, it currently hardcodes hostnames of the form <clustername>.mesh.cilium.io into the etcd configuration for each cluster, even when these names would not be resolvable. This very recently led to an open proposal related to this limitation.

As described in that Issue, it is now possible to use the Helm chart to configure a variety of values that were previously not exposed by this subcommand.

The goal of this task is to make use of the values and configuration logic that now exist in the form of Helm template functions in the upstream chart in order to implement this subcommand.

One of the goals of this implementation is that it should support automatic configuration of a shared Certificate Authority among all clusters using both a cert-manager Issuer-based implementation and and implementation which does not use cert-manager (e.g. Helm-generated or Certgen-based).

[giorio94]

It currently hardcodes hostnames of the form <clustername>.mesh.cilium.io into the etcd configuration for each cluster, even when these names would not be resolvable. This very recently led to a user to open #1539.

One additional point here is that host aliases are configured for the <clustername>.mesh.cilium.io names (since they would otherwise not resolve to valid address) in the cilium agent daemonset. This works fine when the clustermesh-apiserver is exposed through a NodePort/LoadBalancer IP address, while it incurs in possible shortcomings when the LoadBalancer is associated with a DNS name. AFAIK, the current cilium clustermesh connect implementation tries to resolve that DNS name and then configures the resulting IP address(es) as host alias(es). Yet, the DNS name might not be resolvable from the client machine (as mentioned in the issue), as well as this would lead to issues if the underlying IP addresses change.

One additional complexity of directly using the DNS name, though, is that the server TLS certificate needs to match it. The connect command will likely need to also configure proper server.entraDnsNames entries. This cannot be performed while enabling clustermesh, since at that point the hostname might not yet be known.

[asauber]

PR for this feature is up #1628