Create a self-serve registry deployment

The package team is working on container registry more frequently these days which means that the number of changes is growing.

With that grows the need for rolling out changes to our cluster, such as gitlab-com/gl-infra/k8s-workloads/gitlab-com!129 (merged) .

Proposed Solution

1. Upon a tag in gitlab-org/container-registry, trigger a deploy to k8s-workloads/gitlab-com
2. This triggered pipeline will need to receive some information, minimally, the version desired, though we'll need more to ensure the correct pipeline is built.
3. The pipeline will perform its deploy, which closes this issue, and sets a precedent for #552

Proposed work

1. Modify k8s-workloads/gitlab-com to accept information on the registry version and build an appropriate deployment pipeline
2. Modify k8s-workloads/gitlab-com such that it can apply the Container Registry in an idempotent manner, similar to what we did with auto-deploy and sidekiq
3. Make some form of locking mechanism, such that registry deployments, auto-deploy deployments, etc, do not stomp on top of each other
   • This is already a hindrance at times...
4. Build out notification capabilities as already described here:
   • #669 (closed)
   • #526
5. Add safety checks to validate it is safe to proceed with a deployment at each stage
   • This would use metric gitlab_deployment_health:service
   • Currently this does not monitor the registry component so it will need to be added.
6. And finally, something added to gitlab-org/container-registry where upon a tag, it'll send a trigger