[kong] add support for DaemonSets

[rainest]

What this PR does / why we need it:

Add a toggle to use a DaemonSet instead of a Deployment.

Special notes for your reviewer:

Carried over from #269 with some changes to docs and unintended changes.

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])

[mflendrich]

I'm torn.

When I first saw this PR, I was surprised by how easy (on the code) introduction of DaemonSets was in this PR. Then I looked at the API spec for DeploymentSpec and DaemonSetSpec in the k8s api to discover that they're similar, but not the same type - in fact, they share a subset of fields, but the types are not identical. This effectively means that this "unified" template be restricted to the set product of Deployment and DaemonSet fields by making this change, or need to introduce some terrible branching depending on which deployment method was chosen.

To me the "prudent" solution for this (in the strongly typed k8s world) would be to define two conditionally enabled templates (one for a deployment, one for a daemonset) with 99%-100% of the spec being generated by more specific templates, thus avoiding the hack of treating schemas of distinct types as identical.

But maybe that would add complexity to an already bloated chart and we'll never need it 🤷. Time will show, I guess.

Use your best judgment.

[rainest]

There isn't a whole great deal of difference since most of the actual content is in the Pod template, which is the same object type in both. Split templates could move that into _helpers.tpl, which grows ever larger, and has become a bit cumbersome to deal with.

The single template branching approach is effectively what we're doing with the replicas gate, and is probably fine given that there aren't many differences between the two controllers. As for the rest:

• paused doesn't look like you'd manage it with the chart, since you'd instead manage it with kubectl rollout pause/kubectl rollout resume.
• progressDeadlineSeconds we don't use yet, but would need to handle it the same as replicas
• strategy versus updateStrategy is odd since it's fully user-defined and only rendered if set. We could overload the values setting, populate the correct name depending on which controller you're using, and still leave setting the correct contents up to the user.