Webservice: Implement generator pattern to allow traffic splitting across scalable Deployments

What does this MR do?

Convert gitlab/webservice chart into a generator pattern.

Now builds a datamodel under .deployments, and then populates necessary K8s objects with specific data.

Goals:

• Non-breaking behavior, preventing need for a major version change
• No changes in Helm supported versions (currently as far back as v2.14)
• Inheritance from existing properties, but easier maintenance than split-redis pattern (see templates/_datamodel.tpl)
• Ability to close #2334 (closed), by allowing splitting of traffic across groups at the ingress level.

Known caveats:

• Controlling traffic of internal services to various "fleets" requires setting .workhorse.serviceName to webservice-XYZ individually.
• SmartCard will always point to the Service providing .ingress.path: /
• gitlab-webservice objects will now always have a suffix. When no deployments are provided, this results in gitlab-webservice-default.
  • NOTICE This will result in a "blip", because all existing resources are replaced!

Implementation details:

• .deployments is a key based map, where the key denotes the "name" (such as api)
• Resources are generated for each "deployment": Deployment, PodDiruptionBudget, HorizontalPodAutoScaler, Service, Ingress
• Ingress is separated to allow different annotations, such as those for proxy-request-buffer and client-max-body.
• Introduction of gitlab.merge.overwriteEmpty template (currently located within this chart), in order to address the need for "empty wins" merging.

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• [ ] Integration tests added to GitLab QA
• [ ] Equivalent MR/issue for omnibus-gitlab opened

Closes #2334 (closed)

Follow-on work

Revisit reference architecture descriptions, considering to populate the splitting of load between Web, API, and internal API, as with production. It may be feasible to reduce the resources for API alone, but have the larger resources & lower count for Web traffic.

gitlab:
  webservice:
    deployments:
      default:
        ingress:
          path: /
        hpa:
          minReplicas: 8
          minReplicas: 12
        puma:
          workerMaxMemory: 1334
          threads:
            min: 4
            max: 4
        workerProcesses: 2
        resources:
          requests:
            cpu: 2
            memory: 2.75G
      api:
        ingress:
          path: /api
        hpa:
          minReplicas: 12
          minReplicas: 16
        puma:
          threads:
            min: 10
            max: 10
        workerProcesses: 1
        resources:
          requests:
            cpu: 1
            memory: 1.5G