feat: Add Kubewarden resources to the basic and default resourceset

[viccuad]

Part of https://github.com/rancher/kubewarden/issues/7.

This PR adds Kubewarden resources to the basic resourceset (without Secrets) and the default resourceset (with Secrets).

This comprises:

• The default Rancher Namespace catttle-kubewarden-system (or
  cattle-kubewarden-*), and the default Kubewarden Namespace kubewarden.
• Kubewarden needed resources installed via the Helm charts.
• Kubewarden CRDs, which get reconciled after restore by the Kubewarden controller.
• The policy-reporter subchart of the kubewarden-controller chart, for their
  default values. This doesn't include the Grafana integration nor other plugins.

The backup process doesn't include Secrets created to configure PolicyServers
for private registries unless those are correctly labeled by users.

Tested manually by,
applying also #787
and following the steps under kubewarden/docs#632

Documentation in Kubewarden side under:
kubewarden/docs#632

[viccuad]

Rebased, added missing Namespace backups.

[viccuad]

Rebased, added policy-reporter subchart Secrets to the sensitive-resourceset-contents in addition to the (soon to be removed) default-resourceset-contents (from info on #787 (review)).

[viccuad]

Rebased on top of main. Now it adds only to the basic-resourceset-contents and sensitive-resourceset-contents, given that the default-resourceset-contents has been recently dropped.

[juadk]

Tested and automated by Kubewarden QA here => https://github.com/juadk/helm-charts/actions/runs/16470799097 ✅

[jbiers]

Overall this looks good. However, I'm worried about the possible performance implications of having so many rules that do not specify a namespace, implying in a query that searches through all resources of that kind in the entire cluster to find the ones which contain the desired label. Usually we avoid rules like that as much as possible and try to be namespace-specific.

I understand it might be the case that the resources you're trying to include could indeed be located in any namespace. If that is the case, I'd like to at least have these new rules be optional, something that only gets added to the ResourceSets if users explicitly opt-in. My suggestion would be adding a flag in the values file like Values.optionalResources.kubewarden.enabled to control that.

If you need assistance in navigating the codebase to implement those changes let us know and we can help!

[viccuad]

Thanks for the review! Good point. Applied suggestions, now:

• The resources to be backed up are further separated
• Namespaced resources that are user-defined are backed up optionally, with .Values.optionalResources.kubewarden-user-crs.enabled, which is false by default.

[viccuad]

@jbiers fixed the templating problem introduced with adding the optional Value. The resourcesets are under files/, which doesn't allow to use go templating. Instead of refactoring and moving all the resource sets under files/ into templates/, I have added a conditional in the templates for rancher-resourceset-{basic, full}.yaml . Please tell me if that's a fitting change.

Renamed the new value to optionalResources.kubewardenUserCRs.enabled=true instead of optionalResources.kubewarden-user-crs.enabled.

Added 2 new Hull tests for the change.

[jbiers]

@viccuad I opened a PR to your PR (lol) to try to illustrate an approach closer to the behavior I meant by my previous comment: viccuad#1. I only considered the first two commits from your PR which is why my PR shows my branch as stale.

Let me know if that is okay with you.

Also pinging @mallardduck for a review on Monday as my PR changes how the operator builds its ResourceSets so having more people from the team on the know is good.

[viccuad]

Let me know if that is okay with you.

@jbiers Yes, it's totally ok! Thanks for looking into this. Feel free to drop the redone commits from this PR by force pushing it, or to close it and open a new PR. Looking forward to have this merged.

[mallardduck]

lgtm