Add the Required Schema Migrations for the manifests table to populate a new media_type_id_convert_to_bigint column

See Cautionary note below before beginning this issue

We need to test that the background migration process is able to actually migrate data successfully in Gitlab production environments . To test this we have selected a background migration targeting the smallest table in this migration plan:

1.1 Create a column media_type_id_convert_to_bigint bigint not null default 0.

1.2 Create a trigger ON INSERT OR UPDATE SET media_type_id_convert_to_bigint = media_type_id

1.3 Run some sort of background backfill process to set media_type_id_convert_to_bigint = media_type_id. If we don't already have a way to do this it'll be the trickiest step. It's likely a good idea to do this so that each update statement touches a single partition, it would speed the process up a lot. But we should benchmark, perhaps it'll be fast enough no matter what and not worth the complexity.

The overeaching goal is to build confidence in the production migration process by migrating the manifests table to populate a new media_type_id_convert_to_bigint column.

Tasks

We need to add the necessary schema changes to support using the background migrations process to migrate the manifests table media_type_id column to media_type_id_convert_to_bigint. The release of the feature will be monitored in Deploy the manifest table Background Migration ... (#1447 - closed)

• ☣️ Before beginning work on this: first open an MR to disable the background migrations in production introduced in gitlab-com/gl-infra/k8s-workloads/gitlab-com!4109 (merged) before implementing this change. This allows us to guarantee that the background migrations do not mistakingly make it out to production without beign verified (as complete) in staging ☣️ . The background migration worker will then be conciously re-enabled in production in #1447 (closed)