[kong] consolidate Ingress and Service templates

[rainest]

What this PR does / why we need it:

Create helper functions for Ingress and Service generation and refactor existing service templates to use them. Per-service templates now just gate whether to render these for a given service and set up some boilerplate variables.

This avoids copy-paste work when adding new features to these resources, which has historically been a source of inconsistent feature support across them (e.g. previously only the proxy supported explicitly setting a predefined ClusterIP because we forgot to add it to anything else).

This deprecates support for multi-host proxy Ingress resources. Although this has use in some environments (namely when Kong is behind some other ingress controller), it's unnecessary for the stock Ingress we generate, and prevents us from unifying the template. Users will need to write their own Ingress manually (or patch the proxy Ingress after creation--Helm 3 will preserve the change) to use this style of configuration.

Special notes for your reviewer:

• We have to populate a bunch of variables for the helper context, since templates that receive a non-root context don't allow accessing things like .Chart.Name otherwise, and other helpers the new helpers use rely on them.
• This places per-service Service and Ingress templates in the same file, mostly because they need similar sets of boilerplate variables.
• Admin and proxy templates are kind of a mess since they just dump the old legacy template alongside the new template. After 2.0 (which will remove those deprecated configuration options), they'll look like the Manager template.
• This technically allows you to create stream Service configuration on non-proxy services, but nobody should actually do so. It's ultimately harmless (the Service will have some ports that don't actually work) if someone does for some reason.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• PR is based off the current tip of the next branch and targets next, not main
• New or modified sections of values.yaml are documented in the README.md
• Title of the PR and commit headers start with chart name (e.g. [kong])

[rainest]

I'm unsure if multi-host proxy Ingresses are commonly in use. They're something of a historical artifact from the early days of the chart, before our ingress controller existed. Placing Kong behind some other controller's proxy and using that controller to direct traffic to Kong (to match route configuration that had no corresponding K8S configuration) made more sense then. I'd argue it still makes more sense to define Ingresses per application (even if they point to Kong's Service rather than to the application Service) instead of having an omnibus Ingress for all applications, but can't easily say what's in the wild.

If we end up getting user complaints after releasing the deprecation warning, restoring support for it shouldn't be difficult, as the Ingress template is simple (for now, at least, Ingress has far fewer options than Service). We would need to write additional helpers for the rules section of the spec, one supporting the single host+TLS Secret config and one supporting the multi config, and choose which to render using the current legacy logic (whether hostname or hosts is present).

[rainest]

I performed additional manual testing by comparing template output from current next against the consolidated version with ALL THE OPTIONS. full-k4k8s-with-kong-enterprise.yaml.txt and minimal-kong-standalone.yaml.txt cover most, though a few I turned on/off separately. Remaining discrepancies are:

• The proxy metrics label moved from the end to the beginning of the label list. Doesn't actually matter.
• externalIPs is now only rendered if it has content. Previously we rendered an empty block, which serves no purpose.
• All admin templates now include namespace. We missed a bug in [kong] Add kong 'namespace' value #231 that only rendered it when using legacy admin configuration.

[mflendrich]

I'm happy to see a move in this direction. The fact that we need duplicate ingress/service templates to account for legacy stuff is unfortunate (and I'd love to see the consolidated template accommodating the legacy parameters) but I understand that this is outside of scope for this change.

There's some indentation inconsistency. Flagged several issues in line comments, but please join me in reviewing whitespace line by line because I may have missed something. Otherwise LGTM.

[mflendrich]

Suggested change

	{{ toYaml .Values.proxy.ingress.tls | indent 4 }}
	{{- toYaml .Values.proxy.ingress.tls | indent 4 }}

[rainest]

Indentation in the template does bad things to multi-line strings (it only affects the first line), and we do want to preserve the preceding newline here. Leaving as-is.

[rainest]

Missed a bug with legacy proxy TLS sections, hence c7bd903. We don't check those currently in CI because the attempts to start instances will fail if we reference a non-existent Secret, and we don't have any Secrets (TLS or otherwise) available in the test environment.

Edit: fixing this surfaced some very old stuff in CI checks that shouldn't actually be testing legacy config 😐