Install registry CA cert in k8s runner when present

What does this MR do?

GitLab's registry can be configured with a self-signed certificate. This is common in development environments, but may also be done in corporate environments.

By default, self-signed certificates are treated as insecure, and rejected by docker-in-docker builds. This results in x509 errors when interacting with the registry.

To make for a more seamless Auto DevOps experience, and simplify local development, we intorduce an optional configuration field registry.ca, and add configuration to the GitLab-managed runner app to mount the certificate (if present) at runtime at /etc/docker/certs.d/$REGISTRY_HOST_PORT/ca.crt.

This way, docker-in-docker builds work out of the box.

Manual QA

1. The the default still works (no certificate present)

1. attached a cluster
2. installed Runner
3. ran a CI job
4. inspected the in-cluster state

• ✅ the job ran
• ✅ registry data was not added to configmap, no certificate was mounted

2. It works with a valid certificate

1. added registry.ca to my config/gitlab.yml

   registry:
     # ...
     ca: ../registry_host.crt

2. created a kind cluster and attached it to my local GitLab

   • kind has the following config:

     kind: Cluster
     apiVersion: kind.x-k8s.io/v1alpha4
     networking:
       apiServerAddress: 0.0.0.0
     kubeadmConfigPatchesJSON6902:
     - group: kubeadm.k8s.io
       version: v1beta2
       kind: ClusterConfiguration
       patch: |
         - op: add
           path: /apiServer/certSANs/-
           value: gdk.test

   • listen_address is set to a loopback alias IP in gdk.yml, and the corresponding hostname is assigned to this address in /etc/hosts
   • my local registry is self-signed

3. installed GitLab runner

4. ran an Auto DevOps pipeline

Result: ✅ The build job succeeded

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team