GitLab Next

Bring over all the latest changes to the spelling dictionary.

Closes #2516

This adds support for specifying a nodeSelector on the kas deployment.

Introduces an option that helps apply a set of labels spread across all
objects associated with the GitLab Kubernetes Agent (`kas`) chart.  Given the following:

```yaml
global:
  common:
    labels:
      baz: "bat"
gitlab:
  kas:
    common:
      labels:
        foo: "bar"
```

The label set `baz=bat` is applied to all objects created by the GitLab
KAS Chart (⚠ this is to expand to encompass all objects in the
future, but this MR is already large ⚠).  The label set
`foo=bar` is applied to all objects for _**only**_ the GitLab KAS
Chart.

There are additional methods we can apply labels to various objects.

```yaml
global:
  common:
    labels:
      common: label
  pod:
    labels:
      common_pod: label
  service:
    labels:
      common_service: label
gitlab:
  kas:
    podLabels:
      extra_pod: label
    serviceLabels:
      extra_service: label
```

We expect to see all labels appropriately applied to the necessary
objects.  We `merge` items for the chart that we are operating on into
the common labels to help avoid creating duplicate labels.  Example,
labels added specifically to the GitLab KAS chart are merged into the
labels that are provided to the `global.common.labels` section.  We
attempt to manage precedence as best possible leveraging the `merge`
function.  Helm performs the following when building the template:

* `gitlab.kas.podLabels` > `gitlab.kas.common.labels` > `global.pod.labels` > `global.common.labels` => Applies to the Deployment object for the GitLab KAS
* `gitlab.kas.serviceLabels` > `gitlab.kas.common.labels` > `global.service.labels` > `global.common.labels` => Applies to the Service object for the GitLab KAS
* `gitlab.kas.common.labels` > `global.common.labels` => Applies to essentially all other objects other than the above.

Note that we do not interfere with the standard set of labels that we
generate in the `_application.tpl`.  Users will still have the chance of
creating labels that may interfere with each other, but the possibility
should be low as the items generated us in `gitlab.standardLabels` are
very minimal, would interfere with label selectors, and very common in
the helm ecosystem.

Should labels be repetitive, Helm will NOT bail, Kubernetes will NOT
throw a warning, instead Kubernetes will take in the last key value pair
in the label hash.  It is considered invalid YAML and will mark the
appropriate keys as duplicates, and as such this will fail any YAML
linting.

Revise the ordered and unordered lists to bring them closer to
GitLab tone and style.

Related to gitlab-org/cluster-integration/gitlab-agent#87

This is so that:

- The GitLab bundled prometheus can scrape the metrics
- Other prometheus can also scrape the metrics with the standard
annotations

- Foster Helm v3
- Remove suggestion of inexistent helm property --name

To be consistent with Omnibus.

gitlab-org/cluster-integration/gitlab-agent#30

Relates to gitlab-org/gitlab#223060

- Makes it default and required when kas deployment exists
- Fixes its naming
- Unmounts it from the deployment for better security