[CC-4361] Add HCPMetricsBindSocketDir to Envoy bootstrap config

[Achooo]

This PR is very similar to hashicorp/consul#16511 in consul

Background

The HCP Cloud team is working on enabling observability metrics in HCP.
In particular, we want to forward Envoy metrics.

This PR aims to allow Envoy bootstrap configuration of envoy_hcp_metrics_bind_socket_dir, a directory where a unix socket will be created with the name <namespace>_<proxy_id>.sock to forward Envoy metrics.

Code changes

• internal/bootstrap/bootstrap_config.go : Add a HCPMetricsBindSocketDir string type in the BootstrapConfig struct and a function appendHCPMetricsConfig to generate the socket name, configure the stats sink and cluster for metrics forwarding.
• internal/bootstrap/bootstrap_config_test.go: add relevant tests to the above
• pkg/consuldp/bootstrap_test.go: Add a test to generate a golden test file
• internal/bootstrap/bootstrap_tpl.go : small change to move brackets [] into the template instead, which facilitates config generation

Next Steps

There will be a follow-up PR to generate a listener and cluster dynamically that will be listening on this socket
That listener and cluster will be configured to route to collector instances through the service mesh.

Caveat: we needed to add this local listener indirection as a workaround due to this issue

[DanStough]

As we try to add support for VMs to consul-dataplane in the future, I believe using a Unix socket going to be problematic for Windows. Is this a cause for concern?

[Achooo]

After some discussion, it looks like Envoy only supports at least Windows 10, see here, which supports unix sockets, here is the go support.

We'd like to move forward with this, revisit and test as needed when Windows support is in the works. We can always provide an alternative configuration mode for Windows in the worst case if the need arises.

[hashi-derek]

This looks good after having a discussion with Freddy about the feature. Just putting some minor nits here that you don't necessarily have to address.

[hashi-derek]

Rather than defining this as a single value and worrying about concatenating commas in the go code, couldn't we make this variable a slice of strings and do the , joining in the template?

[Achooo]

Yeah I agree the current state isn't ideal... I'd prefer to park this scope-wise!

I believe I'd have to convert the actual BootstrapConfig StatsConfigJSON to a list internally due to these lines

consul-dataplane/internal/bootstrap/bootstrap_config.go

Lines 194 to 196 in dc0da3c

	if c.StatsConfigJSON != "" {
	// StatsConfig overridden explicitly
	args.StatsConfigJSON = c.StatsConfigJSON

, where the args have the actual config reconciled. To convert it externally, this might be a breaking change as it is configurable?

These changes would also affect most test and quite a few areas of the code in bootstrap_config.go and boostrap_config_test.go.

My initial thought seeing this package was maybe there might be a better cleanup that could be done here using marshalling/unmarshalling, although this introduces with defining structs/models, it might reduce the code logic complexity and cleanup a most of these handlings in the code.

But yeah I totally agree the newline handling etc. is not super pretty, I'm also happy to maybe make a follow up PR if that works?

[Achooo]

After testing locally with @freddygv , looks like the Namespace is always default, so we remove the if statement.

We discussed having a safety check to that normalizes to default (e.g. Consul equivalent) but removed it for code simplicity.