Investigate Improvements to gitlab-runner deployments for fleeting runners

[zachariahmiller]

Is your feature request related to a problem? Please describe.

Currently fleeting runner deployments are limited to a single runner pool and need to be deployed numerous times to include different instances sizes/pools.

There are a few issues with this including overhead and complexity of the deployment. This issue is a research spike on the feasibility of achieving some efficiencies in this process.

The areas that should be investigated:

• Deploy x runner pools with one runner manager. This would be investigating if multiple [runners.autoscaling] configurations can be utilized in one runner manager
• Deploy 1x fleeting plugin registry pod for N runner managers
• Investigate and streamline the ability to deploy multiple runner managers and dependent autoscaling configs from a single gitlab-runner zarf package deployment

Describe the solution you'd like

Output of this should be follow on work to implement whatever was proved out as part of the investigation in this issue

Describe alternatives you've considered

use yaml anchors and numerous, largely redundant, helm overrides to faciliate deploying several sets of fleeting runners in a 1 to 1 to 1 of runner manager, runner registry and runner asg.

[Racer159]

Multiple [[runners]] blocks is currently not supported: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/532

[zachariahmiller]

That's disappointing... particularly the closed MR on having the functionality added 2 years ago to then create several new issue about a different means of implementation that has not been touched.