Prepare ci_builds for list partitioning

What does this MR do and why?

It adds the check constraint required for partitioning the table and schedules its async validation. We have a database helper for this, but it validates the constraint synchronously which is a problem for ci_builds since we can't have long running transactions. The helper will be updated to support async options in: #393395 (closed)

It depends on being merged first: !113725 (merged) ✅ merged and executed in production.

How to set up and validate locally

1. Run migrations in the test database: ./scripts/regenerate-schema
2. Open a Rails console in the test environment: bin/rails c -e test
3. Execute the validation: Gitlab::Database::AsyncConstraints::PostgresAsyncConstraintValidation.ordered.check_constraint_type.each { |record| Gitlab::Database::AsyncConstraints::Validators.for(record).perform }
4. ALTER TABLE "ci_builds" VALIDATE CONSTRAINT "partitioning_constraint"; should appear in log/test.log
5. Confirm with the psql console:
   • gdk psql
   • \c gitlabhq_test
   • \d+ ci_builds
   • The NOT VALID part is no longer present in the check constraint definition: "partitioning_constraint" CHECK (partition_id = 100)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #382033 (closed)