Fix partitioning helpers for restricted migrations

What does this MR do and why?

Related to #356276 (closed)

Update a couple migration helpers for partitioning that mix DML and DDL operations. This will no longer be allowed under Gitlab::Database::Migration[2.0], due to the decomposition effort.

In this case we require the helpers to run in one mode or the other, and suppress the checking for blocks which don't follow that model (given that it is safe to do so).

How to set up and validate locally

1. Create a migration to partition a new table db/post_migrate/20220322164616_partition_some_table.rb:

   # frozen_string_literal: true
   
   class PartitionSomeTable < Gitlab::Database::Migration[2.0]
     include Gitlab::Database::PartitioningMigrationHelpers
   
     disable_ddl_transaction!
   
     def up
       create_table :foos, if_not_exists: true do |t|
         t.timestamps_with_timezone
       end
   
       partition_table_by_date :foos, :created_at
     end
   
     def down
       drop_partitioned_table_for :foos
   
       drop_table :foos, if_exists: true
     end
   end

2. Add the foos column here so that the table can be partitioned
3. Run the migrations and verify that the foos table exists in both databases (since this is a DDL change).
4. Create a migration to finalize the backfill:

   # frozen_string_literal: true
   
   class CleanupSomeBackfillMigration < Gitlab::Database::Migration[2.0]
     include Gitlab::Database::PartitioningMigrationHelpers
   
     restrict_gitlab_migration gitlab_schema: :gitlab_main
   
     disable_ddl_transaction!
   
     def up
       finalize_backfilling_partitioned_table :foos
     end
   
     def down
       # no-op
     end
   end

5. Run the migration, which will run for main and for ci will output

   -- Current migration is skipped since it modifies '[:gitlab_main]' which is outside of '[:gitlab_ci, :gitlab_shared]'

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.