Make ECK IPv6 compatible

[pebrc]

IPv6 addresses need to be bracketed when used in resource identifiers. I believe this affects mostly ECK's rendering of configuration files where we use IP addresses for seed hosts and are currently not using brackets for IPv6.

 ["java.lang.IllegalArgumentException: IPv6 addresses must be bracketed: fd00:10:244:0:3::9:9300"

Originally posted by @pebrc in #3408 (comment)

[pebrc]

Also:

cloud-on-k8s/pkg/controller/elasticsearch/certificates/transport/csr.go

Lines 87 to 95 in 18b8936

	generalNames := []certificates.GeneralName{
	{OtherName: *commonNameOtherName},
	{DNSName: commonName},
	// add the transport service name for remote cluster connections initially connecting through the service
	// the DNS name has to match the seed hosts configured in the remote cluster settings
	{DNSName: fmt.Sprintf("%s.%s.svc", esv1.TransportService(cluster.Name), cluster.Namespace)},
	{IPAddress: netutil.MaybeIPTo4(podIP)},
	{IPAddress: net.ParseIP("127.0.0.1").To4()},
	}

and:

cloud-on-k8s/pkg/controller/elasticsearch/settings/merged_config.go

Lines 56 to 57 in bf6201f

	esv1.NetworkPublishHost: "${" + EnvPodIP + "}",
	esv1.NetworkHost: "0.0.0.0",

network publish host is going to be tricky as we are using the downward API to inject the IP address into the configuration. I wonder if we could do something like _eth0_ instead.

[pebrc]

We can sidestep the issue with the embedded PodIP environment variable by switching to domain names for network.publish_host (and potentially also for discovery)

[pebrc]

For Kibana server.host requires us to be explicit about the IP familiy: i.e. for IPv4 we currently have 0.0.0.0 but we would need "::0" for IPv6.

The same problem does not seem to exist for Elasticsearch where the magic value 0 seems to be good enough for network.host for both IP stacks.

We discussed a few options offline:

• spin up the pod unmodified and inspect its IP address then update the configuration with the correct bind address in the next reconciliation
  • disadvantage: slows down rollout of the pod and seems like repeated work for each pod rollout with predictable outcomes on single stack k8s clusters
• detect the IP stack at operator startup
  • either allow the operator request its own pod or inject the pods IP via downward API
  • this would work well for single stack setups but might not be ideal for dual stack setup (which are not in scope for this issue, just thinking ahead)
  • introduce additional configuration options:
    • an operator wide flag
      • seems unnecessary for single stack and too coarse grained for dual stack (I would imagine users would want to control this by per resource)
    • an ipFamily attribute in each supported resource (analogous to the alpha k8s dual stack api)

My gut feeling is that we should

• try to auto-detect the IP family for single use
• add a new field ipFamily or similar for dual stack (not in scope for this issue)