feat(opensearch): make setVMMaxMapCount configurable - #4026

What this PR does

packages/apps/opensearch/templates/opensearch.yaml hardcodes spec.general.setVMMaxMapCount: true, so the opster operator always injects a privileged init-sysctl initContainer. Tenant namespaces carry no pod-security.kubernetes.io/enforce label and therefore inherit the cluster-wide default, which is baseline — and baseline forbids privileged containers. The StatefulSet never creates a Pod, the *-external Services get their LoadBalancer IPs but keep empty EndpointSlices, and the OpenSearchCluster still reports PHASE: RUNNING because only the non-privileged securityconfig Job runs. That is #3022, open since June with no fix.

The chart offers no way out: there is no values knob, so an operator who has already raised vm.max_map_count on the nodes still cannot stop the operator from adding the privileged container. This PR adds setVMMaxMapCount, defaulting to true so nothing changes for existing installations, and threads it into the CR.

Why the default stays true

Flipping the default to false would be the wrong trade. vm.max_map_count is a node-level sysctl, not a namespaced one, so it cannot be set through a Pod securityContext.sysctls — a cluster whose nodes still sit at the Linux default of 65530 would get a Pod that starts and then fails OpenSearch's own bootstrap check instead of failing admission. Worse, anyone who worked around #3022 by labelling the namespace privileged would silently lose the sysctl. Keeping true means this PR is purely additive.

Verification

Measured on a cluster reproducing #3022: nodes report vm.max_map_count = 65530, the machine config carries no vm.* sysctl, and the tenant namespace has no pod-security label, so the cluster-wide enforce: baseline applies and the StatefulSet logs the FailedCreate from the issue verbatim.

New suite tests/vm-max-map-count_test.yaml asserts both branches. Positive control: hardcoding the template back to true turns one of the two cases red, so the asserts really follow the value rather than the literal. Full chart suite 60/60 across 5 suites. values.schema.json, README.md, the generated Go type and the opensearch-rd cozyrds are all updated in step; the cozyrds openAPISchema is byte-identical to jq -c of the schema.

What this does not fix

Half the problem lives outside the chart. Cozystack ships no node sysctls — packages/core/talos builds images only — so an operator still has to set vm.max_map_count=262144 on the nodes before turning this knob off. This PR gives them the switch; whether the platform should ship the sysctl itself is the other half of #3022 and belongs in a separate change.

Refs #3022

Summary by CodeRabbit

• New Features

  • Added the setVMMaxMapCount option for OpenSearch deployments, enabled by default.
  • OpenSearch can automatically configure the required vm.max_map_count system setting using a privileged initialization container.
  • The option can be disabled when the node already provides the required setting or PodSecurity restrictions prevent privileged containers.

• Documentation

  • Documented the new configuration option, default behavior, and when to disable it.

• Tests

  • Added coverage for the default-enabled behavior and explicit disabling.