U-6624: Kubernetes service discovery

[curusarn]

• Run kubernetes service discovery if kubernetes_discovery_* wildcard is used in vector config
• Validate generated kubernetes discovery vector configs with minimal main config -> reject generated config if validation doesn't pass to prevent kubernetes discovery breking the entire config
• Validate upstream vector config after download, use minimal kubernetes discovery config -> keep downloaded version if validation fails, update symlink to latest valid version if validation passes (send any validation errors to Better Stack)
• Validate final upstream vector config + actual generated -> promote valid config + SIGHUP vector, on validation fail send errors to Better Stack

[curusarn]

For context:

We have upstream vector config coming from Better Stack.
This PR adds a way to additionally give vector extra configs for discovered services (pods) in the cluster based on standard Prometheus labels.
We'll reference the sources via kubernetes_discovery_* glob in the main vector config.

Problems this PR addresses that came up during development:
Vector will error for configs that contain globs that don't match anything - e.g. no_sources_with_this_prefix_* will cause vector to fail.

• This is problematic as we can no longer download upstream config and validate it separately. -> We validate with a minimal dummy service discovery config.
• Another problem is if there are no services discovered. -> Again, we solve this with minimal empty service discovery configs.

Under no circumstances the vector should crash because of broken upstream config, broken dynamic discovery configs, or some odd combination of both.
We triple validate the vector config:

• Upstream config is only used if it passes validation with minimal service discovery config.
• Dynamic configs are deleted if they don't pass validation with minimal base vector config.
• Both separately validated configs are validated together and only used if they pass validation.

Any errors in Upstream config or the final combination of configs is sent to Better Stack UI via "ping".
Errors in dynamic configs are logged but not surfaced to the user.

Kubernetes discovery:

• Aimed to be close to what Prometheus does.
• Only scrape metrics from pods on the same node.
• Use local node network.
• Tag metrics with Service object if pod has one.
• Tag pods with workload name - context: https://linear.app/betterstack/issue/T-8738/feature-collector-track-workloadservice-name-and-replicacontainer-name
• Kubernetes discovery won't run if the upstream vector config doesn't reference kubernetes_discovery_* so that we don't burn CPU

[paweljw]

Thanks! Looks good to me 🙏