Add default policy server settings

[ereslibre]

Fixes: #76

This adds a global values.yaml file that can be consumed by the subcharts on certain attributes that might be shared across them.

For installation, the current documentation can be followed, running:

$ helm install --wait -n kubewarden --create-namespace kubewarden-crds charts/kubewarden-crds -f values.yaml
$ helm install --wait -n kubewarden kubewarden-controller charts/kubewarden-controller -f values.yaml
$ helm install --wait -n kubewarden kubewarden-defaults charts/kubewarden-defaults -f values.yaml

You can read more about global values at https://helm.sh/docs/chart_template_guide/subcharts_and_globals/#global-chart-values

[raulcabello]

LGTM, but this will change once we have a separate chart for the default PolicyServer
I would love to find a way of installing the 3 charts, and use the same values file. That way we could use the same default PolicyServer name. I'm not sure if that is possible

[ereslibre]

Converting to draft until prerequisites are merged and figured out.

[ereslibre]

kubewarden/kubewarden-controller#175 was merged too and unblocked this.

I'm going to rebase this PR on top of main.

[raulcabello]

LGTM, thanks!

[viccuad]

It looks ok to me, but with this we have 3 values files (1 per chart), plus the global values. I would prefer to merge them all into global values already, to only need one yaml as UX. But we can do that in a follow-up PR that closes #76.

[ereslibre]

@viccuad We can discuss about it. I am in principle more in favour for each chart to encapsulate the values that make sense to that specific chart, and on the globals section, put values that are to be shared (and need to be in sync) across more than one helm chart/subchart.

This discussion goes on at #76

[ereslibre]

Converting to draft because if published the toplevel values.yaml is not going to be consumed by helm. Looking into how we could make this work.

[ereslibre]

Based on the discussions on issue #76 I have updated this PR to be a middle ground.

values.yaml are not overdesigned by adding multiple artificial toplevel keys. They look very much the same as they did. A new toplevel key common is added and it's duplicated across charts that require to access this common attributes.

This allows a user to reuse the same values.yaml across all charts, and for common settings to match without hassle.

If we agree to go on with that I think we can add some automation as @viccuad proposed for linting and ensuring that we don't get key overrides. This task could be done afterwards this merges.

[viccuad]

LGTM! Thanks for the effort on this topic.

[raulcabello]

LGTM, thanks @ereslibre!

[jvanz]

LGTM

[ereslibre]

This will be changed very soon, when we release the helm chart too.