Remove default for daemonset/deployment in eck-beats & eck-agent Helm Charts

[naemono]

resolves #6330

Since helm/helm#11440 is still open/unresolved, we really need to not set a default deployment/daemonset for both eck-agent and eck-beats helm charts as they simply cannot be removed when using a "parent" helm chart pattern, such as in eck-stack.

open question, should we do the same for eck-fleet-server, since that deployment mechanism is typically a deployment?

# deployment.yaml
eck-elasticsearch:
  enabled: false

eck-kibana:
  enabled: false

eck-beats:
  enabled: true

  version: 8.5.3
  spec:
    type: filebeat
    daemonSet: null
    config:
      filebeat.inputs:
      - type: container
        paths:
        - /var/log/containers/*.log
      processors:
      - add_host_metadata: {}
      - add_cloud_metadata: {}
    deployment:
      replicas: 1
      podTemplate:
        spec:
          containers:
            - name: filebeat
              securityContext:
                runAsUser: 1000

# Note that `daemonSet` cannot be removed when using a parent chart pattern, such as `eck-stack`
❯ helm template eck-stack  . --values ./examples/beats/deployment.yaml | yq e '.spec' -
version: 8.5.3
type: filebeat
config:
  filebeat.inputs:
    - paths:
        - /var/log/containers/*.log
      type: container
  processors:
    - add_host_metadata: {}
    - add_cloud_metadata: {}
daemonSet: {} <==== Note this still exists
deployment:
  podTemplate:
    spec:
      containers:
        - name: filebeat
          securityContext:
            runAsUser: 1000
  replicas: 1
elasticsearchRef:
  name: elasticsearch
type: filebeat

[thbkrkr]

Do we need this or change how we run helm lint?

Because running the linter without it doesn't fail there is just an extra INFO level log.

> helm lint --strict .; echo $?
engine.go:176: [INFO] Missing required value: A Beat type is required
engine.go:189: [INFO] Fail: At least one of daemonSet or deployment is required for a functional Beat
==> Linting .

1 chart(s) linted, 0 chart(s) failed
0

[naemono]

@thbkrkr I swore mine was failing without this in place.. I'll verify/

[naemono]

Yeah the Fail confused me, I think, and I didn't check the return value. I've removed this.

[thbkrkr]

It's not from your PR, but we are not consistent with the daemonSet/deployment defaults for Beats and Agent.

[naemono]

I believe I made them look consistent in the values @thbkrkr lmk.

[thbkrkr]

👍

[naemono]

@elasticmachine run elasticsearch-ci/docs