Get rid of logs in interactive CLI commands

[L3n41c]

What this PR does / why we need it:

This PR aims at removing the logs from the interactive CLI commands executed by end users.

Currently, when a user runs an interactive CLI command like agent status or agent configcheck, the human readable output is polluted by logs:

$ kubectl exec pod/datadog-agent-linux-bq8p2 -c agent -- agent status 2>/dev/null

2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/util/log/log.go:826 in func1) | Starting to load the configuration
2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/util/log/log.go:826 in func1) | Loading proxy settings
2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/util/log/log.go:826 in func1) | Starting to resolve secrets
2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/util/log/log.go:826 in func1) | Finished resolving secrets
2024-08-12 09:55:23 UTC | CORE | WARN | (pkg/util/log/log.go:871 in func1) | Deactivating Autoconfig will disable most components. It's recommended to use autoconfig_exclude_features and autoconfig_include_features to activate/deactivate features selectively
2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/config/setup/config.go:1861 in LoadCustom) | Starting to load the configuration
2024-08-12 09:55:23 UTC | CORE | INFO | (pkg/config/setup/config.go:1545 in LoadProxyFromEnv) | Loading proxy settings
2024-08-12 09:55:23 UTC | CORE | WARN | (cmd/system-probe/config/adjust.go:150 in deprecateCustom) | configuration key `runtime_security_config.activity_dump.cgroup_dump_timeout` is deprecated, use `runtime_security_config.activity_dump.dump_duration` instead
Getting the status from the agent.

=====================
Agent (v7.56.0-rc.10)
=====================
  Status date: 2024-08-12 09:55:23.573 UTC (1723456523573)
  Agent start: 2024-08-12 09:52:06.064 UTC (1723456326064)
  Pid: 3869739
[…]

An even more nastier effect is that, because of those logs, the output of commands run with --json isn’t JSON valid:

$ kubectl exec pod/datadog-agent-linux-bq8p2 -c agent -- agent status --json | jq

parse error: Invalid numeric literal at line 1, column 11

This is because the DD_LOG_LEVEL environment variable is set not only for the main container process (the agent daemon itself), but also for all the commands interactively executed with kubectl exec.

This fix sets the DD_LOG_LEVEL environment variable only for the main container process directly inside the command: property. So, commands executed via kubectl exec don’t have DD_LOG_LEVEL set anymore:

$ kubectl exec pod/datadog-agent-linux-m2nrz -c agent -- agent status

Getting the status from the agent.

=====================
Agent (v7.56.0-rc.10)
=====================
  Status date: 2024-08-12 10:02:28.885 UTC (1723456948885)
  Agent start: 2024-08-12 10:00:39.262 UTC (1723456839262)
  Pid: 3884339
[…]

The JSON commands’ output is now JSON valid:

$ kubectl exec pod/datadog-agent-linux-m2nrz -c agent -- agent status --json | jq

{
  "JMXStartupError": {
    "LastError": "",
    "Timestamp": 0
  },
  "JMXStatus": {
    "info": null,
    "checks": {
      "initialized_checks": null,
      "failed_checks": null
[…]

Which issue this PR fixes

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Chart Version bumped
• Documentation has been updated with helm-docs (run: .github/helm-docs.sh)
• CHANGELOG.md has been updated
• Variables are documented in the README.md
• For Datadog Operator chart or value changes update the test baselines (run: make update-test-baselines)

[gjulianm]

LGTM for ebpf-platform file

[gjulianm]

I see some containers have a | quote filter on the log level (otel-agent ) and others don't. Why the difference?