Container Registry: allow setting database configuration even if set to false

What does this MR do?

We want to allow setting the database configuration for the registry chart even when registry.database.enabled is set to false. To do so, we've introduced a new flag registry.database.configure: true that will allow the settings to be propagated to the registry related resources without needing the enabled flag to be set.

To keep backwards compatibility, we will fill the database configuration when registry.database.enabled: true, regardless of the value of registry.database.configure. See the specs for examples.

This will unblock Document three-step migration process for Helm ... (gitlab-org/gitlab#439684 - closed), as for the first step of migration process requires:

1. The database to be disabled
2. The migrations-job to have completed

For step 2, we require the registry to go into read-only mode. This is possible by setting registry.maintenance.readonly.enabled to true.

For details on the 3-step migration process see https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html#three-step-migration.

Test plan

1. Install the chart with the registry enabled.

2. Save the helm values to a file, e.g. values.yml

3. Create the registry database

4. Configure the database section with registry.database.enabled false, for example

   registry:
     configure: true
     enabled: false
     database:
       enabled: true
       name: registry # must match the name of the database created in step 3
       user: registry # must match the username of the database created in step 3
       password:
         secret: gitlab-registry-database-password # must match the secret name created in step 3
         key: password 
       migrations:
         enabled: true

5. Apply the values changes in your cluster

6. Verify the registry-migrations-* job completed successfully, e.g.

   kubectl logs gitlab-registry-migrations-13-gv5fh
   Defaulted container "migrations" out of: migrations, certificates (init), configure (init)
   Begin parsing .tpl templates from /etc
   Copying other config files found in /etc to /etc/docker/registry
   OK: applied 155 migrations in 13.752s

7. SSH into the registry container of the registry pod. E.g. kubectl exec -ti gitlab-registry-57f9459985-b52nh -c registry bash

8. Verify the database configuration is set:

$ cat /etc/docker/registry/config.yml
...
database:
  enabled: false
  host: "gitlab-postgresql.default.svc"
  port: 5432
  user: registry
  password: "<REDACTED>"
  dbname: registry

Related issues

Related to Container Registry: allow setting database conf... (#5292 - closed)

Author 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
• When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow

For merge requests from forks, consider the following options for Danger to work properly:

• Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
• Alternatively, see our documentation on configuring Danger for personal forks.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added/updated
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes) -> gitlab-org/cloud-native/gitlab-operator#1599 (closed)
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

Closes #5292 (closed)