Naive noProxy breaks OpenTelemetry components

[krx252525]

Describe the bug #3022 fixed an issue with the overzealous chomping of whitespace when specifying httpProxy and/or httpsProxy parameters in the helm chart.

However, the default sumologic.noProxy setting results in OpenTelemetry components breaking as everything except kubernetes.default.svc will get proxied, for example :::55678 gets proxied in otelcol-instrumentation.

I'm a bit confused why :::55678 is being used since we use a single stack IPv4 networking.

Logs I can't share logs here but happy to open a support ticket if necessary

Command used to install/upgrade Collection helm upgrade --install ...

Configuration Mostly default for the purpose of this bug

sumologic:
    httpProxy: "http://someproxy.tld:3128"
    httpsProxy: "http://someproxy.tld:3128"
    # this is the default
    noProxy: kubernetes.default.svc

To Reproduce Configure

Expected behavior A clear and concise description of what you expected to happen. I would expect defining a proxy to work without having to inspect each of the individual components/

Environment (please complete the following information):

• Collection version (e.g. helm ls -n sumologic): 3.5.0 (but the same value is used in main)
• Kubernetes version (e.g. kubectl version): 1.24.11-gke.1000
• Cloud provider: GCP
• Others: N/A

Anything else do we need to know This noProxy appears to work in place of the default and should serve as a sensible default:

sumologic:
  noProxy: '.cluster.local,.svc,::'

There are warnings stating in the otelcol logs: "Using the 0.0.0.0 address exposes this server to every network interface, which may facilitate Denial of Service attacks" As described in the otel-collector/security-best-practices.md. Following the advice there to use localhost in place of 0.0.0.0 makes the correct noProxy a bit easier on the eye, tested and appears to work (can't comment on IPv6):

sumologic:
  noProxy: .cluster.local,.svc,localhost