Refactor migrations of Registry chart into sub-chart

The following discussion from !4358 (merged) should be addressed:

• @WarheadsSE started a discussion: (+13 comments)

  @clemensbeck @Alexand

  Let's proceed with this as it is, but perhaps raise an item to refactor the migrations of the Registry chart into a sub-chart, which could be operated individually in the future.

  While this will work for our own operations teams, I do not like this pattern for Self-Managed customers as a whole. This works but its use is painful.

Proposal

1. Take the Registry chart and break it into two sub-charts: 1 for the service, another for migrations. Similar to what we have for Rails webservice and Rails Migrations.
   • It might be better to duplicate this logical split while we don't introduce the breaking change, and add a flag which default to migrations with the current existing values from the embedded migration job. When the flag is toggled, then it would enable the new subchart, and disable existin the migration job. This allows us to keep backwards compatible until the major milestone, and not have 2 jobs running the same migration.
2. Then re-document how to operate PostDeployment migrations with the split registry migration sub-chart.
3. Deprecating some chart keys, documenting, and announcing how the users will migrate their registry migration keys to the new sub-chart. (has to be rolled out on a major milestone). Deprecation should include:
   • Follow the deprecation/removal guidelines from https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/doc/development/deprecations.md.
   • Policies and recommendations for deprecations on the company-wide doc also applies: https://docs.gitlab.com/development/deprecation_guidelines/. This means, be aware of the timelines, and also inclusion of deprecation on https://docs.gitlab.com/update/deprecations/
   • After the major milestone we have to clean up this flag along with the previous migration scheme.
4. Notify the groupdelivery-deploy (and/or groupdedicated ?) about the change so that they adapt their deployments to the new way. We need to make sure that we coordinate this changes with GET and .com, so that we don't introduce the breaking change before they are ready.