enable strict JSON spec unmarshalling

[AndrewChubatiuk]

related issue VictoriaMetrics/helm-charts#2882

---

Summary by cubic

Enable strict JSON unmarshalling for all Operator CR specs to reject unknown fields and return clear errors. This prevents typos or unsupported keys from being silently accepted.

• Bug Fixes

  • Added UnmarshalSpecStrict (uses DisallowUnknownFields) and wired all CR UnmarshalJSON paths (v1, v1alpha1, v1beta1) through it, setting ParsingSpecError on failure.
  • Updated VMAlertmanagerConfig tests/fixtures to use valid fields (e.g., msteams_configs, custom_fields placement).
  • Added a changelog entry documenting the behavior change.

• Migration

  • Manifests with unknown or misspelled spec fields will now be rejected by the webhook; fix or remove extra keys before applying.

^{Written for commit a984354. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 25 files

_{Re-trigger cubic}

[vrutkovs]

I think this would break invalid Prometheus CRs:

• A CR with extra fields created
• Controller unmarshals it, sets status.ParsingSpecError
• Here we don't set the status to Failed, so error is basically invisible
• This field is not persisted to etcd, so on next reconcile we start again

Another issue - during upgrade we apply new CRDs when old operator is running:

• CRD removes a field
• Old operator is using new CRD, parses existing CR
• Extra field detected, CR is moved to failed

until operator is upgraded. In existing mode it would just be silently skipped.

I'm not convinced we should change existing behaviour, however a good documentation around this choice would be useful

[vrutkovs]

I wonder if we can limit strict parsing to new objects only - perhaps in a webhook?

[AndrewChubatiuk]

anyway in a linked issue I've described workaround, created this PR just in case

[AndrewChubatiuk]

• A CR with extra fields created
• Controller unmarshals it, sets status.ParsingSpecError
• Here we don't set the status to Failed, so error is basically invisible
• This field is not persisted to etcd, so on next reconcile we start again

seems like expected behavior when webhooks are enabled. currenty webhooks reject CRs with specs that have fields with invalid data type or value and mark resource as failed and allow to apply it when webhooks are disabled. with this change the same behaviour is added for unsupported fields.

Another issue - during upgrade we apply new CRDs when old operator is running:

• CRD removes a field
• Old operator is using new CRD, parses existing CR
• Extra field detected, CR is moved to failed

we keep noop CR properties for a long time, so this concern should be covered as well