Configurable tables to check for vacuum for background migrations

What does this MR do and why?

Background migrations not always write to the table they iterate on. In these cases it does not make sense to put the migration on hold because of vacuum running for this table. This provides a way for migration to explicitly provide list of tables to be checked for vacuum activity.

For example we can update BackfillMergeRequestFileDiffsPartitionedTable like

diff --git i/lib/gitlab/background_migration/backfill_merge_request_file_diffs_partitioned_table.rb w/lib/gitlab/background_migration/backfill_merge_request_file_diffs_partitioned_table.rb
index d24cbea61e7d..ed7d7c6dd366 100644
--- i/lib/gitlab/background_migration/backfill_merge_request_file_diffs_partitioned_table.rb
+++ w/lib/gitlab/background_migration/backfill_merge_request_file_diffs_partitioned_table.rb
@@ -10,6 +10,8 @@ class BackfillMergeRequestFileDiffsPartitionedTable < BackfillPartitionedTable
 
       cursor :merge_request_diff_id, :relative_order
 
+      tables_to_check_for_vacuum :merge_request_diff_files_99208b8fac
+
       override :perform
       def perform
         column_values = connection.columns(batch_table).map do |column|

so that the migration will be put on hold when there is vacuum running for merge_request_diff_files_99208b8fac and not for merge_request_diff_files.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

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