fix(kibana): discard unknown saved objects on upgrade from 7.x

[tianfeng92]

Summary

Set migrations.discardUnknownObjects on the Kibana CR so CE 3.20 → 3.21+ upgrades no longer crashloop on the orphan ingest_manager_settings saved-object document.

Problem

In operator v1.38 (PR #4323), Fleet was disabled via xpack.fleet.enabled: false to silence outbound traffic from the Fleet plugin (e.g. ProductDocBase:EnsureUpToDate → kibana-knowledge-base-artifacts.elastic.co). That change had an unintended consequence:

• CE 3.20 (Kibana 7.17) shipped with Fleet enabled by default. On first boot, Fleet's init logic wrote one saved object into .kibana: type: ingest_manager_settings, id fleet-default-settings, containing an empty default-settings body.
• CE 3.21 (Kibana 8.19, operator v1.38) disables Fleet → the ingest_manager_settings SO type is no longer registered.
• Kibana 8.0 introduced strict saved-object migration: unknown types are fatal (7.x only warned).
• Upgrading 3.20 → 3.21+ hits CHECK_UNKNOWN_DOCUMENTS → FATAL and Kibana crashloops.

Reproduced on lab upgrades: 3.19.4→3.21.6, 3.19.4→3.22.2, 3.20.7→3.22.2, 3.20.7→3.21.6.

Fix

Set migrations.discardUnknownObjects: <kibana-version> in the Kibana CR's spec.config. Kibana's migration then discards any docs whose type has no registered owner instead of erroring out. The setting is version-pinned, so it only takes effect for the current migration — no risk of silently eating data during future upgrades.

Value is sourced from components.ComponentEckKibana.Version (same constant used for Spec.Version), guaranteeing they can't drift.

Validation

Built and deployed this patch to a lab CE 3.21.6 cluster that was crashlooping with the ingest_manager_settings FATAL. After the operator reconciled and wrote migrations.discardUnknownObjects: "8.19.10", Kibana pods came up 1/1 Running on next restart, with Migration completed logs for all 6 .kibana* indices. No FATAL.

Cherry-pick targets

• release-v1.38 (CE 3.21) — branch: tianfeng92:fix-kibana-discard-unknown-objects-v1.38
• release-v1.40 (CE 3.22)
• release-v1.42 (CE 3.23) — if still active

Test plan

• Unit test updated in kibana_test.go asserting the setting is rendered
• go test ./pkg/render/logstorage/kibana/ passes
• Manual end-to-end validation against lab CE 3.21.6 cluster (build + deploy + observe recovery)

🤖 Generated with Claude Code

Release Note

Fix Kibana crashloop when upgrading from Calico Enterprise 3.20 or earlier to 3.21+. The orphan `ingest_manager_settings` saved object left by Fleet 7.17 is now discarded during Kibana 8.x's saved-object migration, allowing the upgrade to complete successfully.

Caveat discovered during v1.40 validation

The value is sourced from components.ComponentEckKibana.Version. This constant must match the actual Kibana binary version shipped in the tigera/kibana image. Kibana ignores migrations.discardUnknownObjects when the configured version string doesn't equal its own internal version (logs The flag ... does not match the current kibana version; unknown objects will NOT be discarded).

While validating on a CE 3.20 → 3.22 upgrade, we found that operator release-v1.40 has drifted: ComponentEckKibana.Version = "8.19.12" but the released quay.io/tigera/kibana:v3.22.2 image still ships an 8.19.10 binary. That drift is pre-existing and independent of this PR, but it blocks the cherry-pick to release-v1.40 from taking effect until one of:

• ComponentEckKibana.Version is reverted to "8.19.10" on release-v1.40 (matches the image), or
• the tigera/kibana 3.22 image is rebuilt against upstream Kibana v8.19.12 (matches the constant)

release-v1.38 (ComponentEckKibana.Version = "8.19.10", image also 8.19.10) is fine as-is — confirmed end-to-end on a CE 3.20 → 3.21 upgrade.

Suggest owners of release-v1.40 / release-calient-v3.22 treat the constant-vs-image sync as a precondition for cherry-picking this fix.