Create partitions for p_ci_build_trace_metadata - 2nd try

What does this MR do and why?

On the CI database we tried to recreate ci_build_trace_metadata as a partition of p_ci_build_trace_metadata, but after a few failed attempts we gave up and tried a different plan which also failed: !168365 (comment 2151393647)

With this we're letting the sidekiq workers to create the partitions.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. gdk psql -d gitlabhq_test_ci
2. \d+ p_ci_build_trace_metadata - confirm that ci_build_trace_metadata is a partition of p_ci_build_trace_metadata
3. drop table ci_build_trace_metadata; - drop the table to emulate the CI database state from production: https://console.postgres.ai/gitlab/gitlab-production-ci/sessions/32407/commands/100105
4. bin/rails c -e test - start a Rails console in a new window
5. Feature.enable(:partition_ci_build_trace_metadata)
6. Gitlab::Database::Partitioning.sync_partitions_ignore_db_error
7. \d+ p_ci_build_trace_metadata - confirm that the new partitions are present

   Partitions: gitlab_partitions_dynamic.ci_build_trace_metadata_100 FOR VALUES IN ('100'),
               gitlab_partitions_dynamic.ci_build_trace_metadata_101 FOR VALUES IN ('101'),
               gitlab_partitions_dynamic.ci_build_trace_metadata_102 FOR VALUES IN ('102')

8. ./scripts/regenerate-schema - reset your testing database to its original form

Related to #469056 (closed)