Config overrides: use apiVersion instead of group for easier UX

[frobware]

This is an experiment building on @andreaskaris's work in #475.

After reviewing the override functionality, I wanted to explore a couple of changes that I think make the feature easier to use and more robust.

What changed

1. Replace group with apiVersion in the override spec

The original implementation required users to specify:

- kind: DaemonSet
  group: apps
  namespace: bpfman
  name: bpfman-daemon
  unmanaged: true

This means users need to remember API group names (apps, storage.k8s.io, empty string for core resources, etc.) and mentally split apiVersion into group/version.

The new approach uses apiVersion directly:

- apiVersion: apps/v1
  kind: DaemonSet
  namespace: bpfman
  name: bpfman-daemon
  unmanaged: true

This is the same format users see in kubectl get -o yaml output, so they can copy/paste directly. No need to remember that ConfigMaps have an empty group or that DaemonSets live in apps.

2. Use scheme-based GVK resolution

The original implementation matched overrides using resource.GetObjectKind().GroupVersionKind(). This is fragile because many objects constructed in code don't have their TypeMeta populated - it's only reliably set when objects are decoded from the API server.

The PR had already worked around this by manually adding TypeMeta to the ConfigMap:

cm := &corev1.ConfigMap{
    TypeMeta: metav1.TypeMeta{
        Kind:       "ConfigMap",
        APIVersion: "v1",
    },
    // ...
}

The new approach uses the controller's scheme to resolve GVK:

gvks, _, err := scheme.ObjectKinds(resource)

This works reliably for all objects regardless of how they were constructed, so we can remove the manual TypeMeta workaround.

Testing

I've tested this on a kind cluster:

1. Added an override for the DaemonSet
2. Verified the operator logs show "Skipping unmanaged resource (override in place)"
3. Modified the DaemonSet spec - changes persisted (operator skipped it)
4. Deleted the DaemonSet while unmanaged - it stayed deleted
5. Removed the override - operator recreated the DaemonSet

The escape hatch semantics work as expected: complete hands-off while unmanaged, operator resumes control when the override is removed.

Summary

These changes are subjective improvements for UX and robustness. The core override functionality from #475 is unchanged - this just makes it easier to configure and removes a potential source of silent matching failures.

Happy to discuss if there are concerns or alternative approaches.

[frobware]

This was done in #475.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (b1de326) to head (7d6c080).
⚠️ Report is 27 commits behind head on main.

Additional details and impacted files

@@     Coverage Diff     @@
##   main   #489   +/-   ##
===========================
===========================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.