Add experimental support for Gitaly on Kubernetes in GKE

What does this MR do?

MR adds experimental support for deploying Gitaly on Kubernetes in GKE for testing / evaluation purposes only as the feature is considered development complete but still not recommended for production at this time.

Note: Experimental support in GET is only added added for evaluation or testing purposes and is strictly unsupported for production use and subject to change.

Setup is designed for a future architecture type where Gitaly pods are deployed on nodes exclusively to assure performance and stability and to avoid various potential challenges with noisy neighbours, blast radius, etc.... The pods are configured as recommended for this sort of setup - Specifically cgroups are enabled by default with a memory buffer of 10% in place and a 6GB cap determined from extensive performance testing.

Additionally, with this new deployment type means several previous certainties are no longer certain in the Toolkit - Specifically the guarantee of at least one Omnibus node in place that Ansible was able to use in a semi-bastion fashion. That in turn requires some rearchitecting of some pathways as follows:

• External Postgres prep - For CN environments this is now done by a deployed Postgres pod in the Kubernetes cluster (to reach the database internally)
• Secrets support - Secrets support remains the same but new documentation has been added to call out the differences between Omnibus and Charts secrets.

Related issues

Closes https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/issues/945 #959 (closed)

Author's checklist

When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up-to-date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
  • MR has no new security alerts in the widget from the Secret Detection and IaC Scan (SAST) jobs.
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: set up a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Self-Managed Platform team if unsure.