Skipping 22.0.2 as recommended by release notes.

References:
https://www.keycloak.org/2023/09/keycloak-2203-released.html

This patch adjusts the keycloak helm chart to use the upstream
recommended paths for exposing keycloak. It also adjusts the current
deployment to utilise a dedicated, further restricted admin interface.

BREAKING CHANGE: This commit will remove the exposure of the admin
interface as well as other exposed URLs.

References:
https://www.keycloak.org/server/reverseproxy#_exposed_path_recommendations

The helm-unittest upstream has switched back to the helm-unittest
organisation again. Therefore switching to a different image. With the
switch a few minor, but breaking changes have been introduced.

- Dropping helm v2 support
- adjustment of indentation
- enforcing jsonpath for selection

Reference:
https://github.com/helm-unittest/helm-unittest

This patch upgrades keycloak to 20.0.0 and implements the new
adminHostname feature by adding the required variables and a separate
ingress object, which can be utilised for the admin URL and restrict it
independent of the regular frontend.

This patch configures renovate to allow manual addition of a comment
that specifies the image which a helm chart deploys. Should make sure
that no image updates are missed.

This patch adds a new snapshot test that should cover most resources of
the helm chart, instead of just the basic ones, it also renames the
existing job to properly represent what it compares to. This will also
allow to better monitor some of the more complex resources that are
deployed by the chart.

This patch should simply check all resources created by the chart to
contain the recommended Kubernetes labels to be properly identified as
part of the helm chart.

References:
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

When using infinispan the app startup is a bit slower. As a result,
it'll might cause a termination of the keycloak instance before it's
fully in sync and therefore breaks HA. This patch introduces a startup
probe that resolves this issue by waiting for a successful startup
before the livenessprobe kicks in and might terminates the pod at any
point when it's actually failing again.

References:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes