Add securityContexts.disableDefaults flag for OpenShift SCC compatibility

[Aaryan123456679]

OpenShift assigns runAsUser/fsGroup automatically via SCC and rejects pods that hard-code them, so users need to null these out in the rendered pod securityContext. The Helm chart's values.schema.json typed securityContexts.pod.runAsUser/runAsGroup/fsGroup as non-nullable integers (via the vendored io.k8s.api.core.v1.PodSecurityContext definition), so setting them to null failed schema validation before the templates ever rendered — the templates themselves already pass through explicit nulls correctly.

This introduces a new AirflowPodSecurityContext schema definition (not io.k8s.*-prefixed, so it survives vendor_k8s_json_schema.py regeneration) that allows null for these three fields, and points all 16 securityContexts.pod $refs at it instead of the vendored definition.

closes: #41630

Test plan

• Added test_main_pod_setting_runasuser_fsgroup_null verifying runAsUser/fsGroup render as None when explicitly nulled
• breeze testing helm-tests --test-type security — 188 passed
• breeze testing helm-tests --use-xdist (full suite) — 2061 passed
• Verified via helm template that the schema now accepts the null override and the rendered manifest's spec.template.spec.securityContext reflects the explicit nulls

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Sonnet 5)

Generated-by: Claude Code (Sonnet 5) following the guidelines

[Miretpl]

I would see it more like adding a flag which would make all of the default options not added. Currently, in most cases (if not in all), if securityContexts.* is empty, in the helper function logic we are adding some values. I think they should not be added there, and if we want to have some default values in the chart for them, they should be in the values.yaml file (version 2.0).

In this PR, I would add a flag for not adding these default values in the helper function when, e.g. securityContexts.pod is {} (default in values.yaml file). This would be, IMHO, much more intuitive for the users; in the end will require less logic to handle and maintain and should be cleaner too.

WDYT?

[Aaryan123456679]

Thanks for the suggestion — that's a cleaner approach. I've reworked the PR accordingly:

• Added a securityContexts.disableDefaults flag (default false). When set, the chart no longer fills in the default runAsUser/fsGroup (pod) or runAsUser (container) values wherever securityContexts.pod / securityContexts.containers (or the per-component overrides) are left empty — the securityContext key is omitted from the rendered manifest entirely, rather than emitting an explicit null.
• Reverted the values.schema.json change back to the vendored io.k8s.api.core.v1.PodSecurityContext ref (dropped the earlier AirflowPodSecurityContext nullable-fields workaround), since the flag makes that special-casing unnecessary.
• Explicit values in securityContexts.pod / securityContexts.containers (global or per-component) still take priority over disableDefaults, so existing fine-grained overrides are unaffected.
• Updated the newsfragment, production-guide.rst, and test_security_context.py to describe the flag instead of the null-based workaround.

Let me know if this matches what you had in mind, or if you'd adjust the flag's scope or naming.