Move partitioning backfill migration to post-deploy

What does this MR do?

Relates to #230815 (closed)

Migration helpers to partition a table perform multiple steps at once, including adding the new table, installing a trigger to copy changes, and enqueuing a background migration to copy historic data. However, there is a downside to doing this as a single step. If done in a standard migration, the background migrations may refer to code not yet deployed to the fleet. If done in a post-deploy migration, the schema changes won't occur until after new code is already active.

For this reason, the helpers should be split into multiple methods to control the time they execute. The existing helper method partition_table_by_date will continue to be called from a standard migration, but will only create the new schema objects. The new helper method enqueue_partitioning_data_migration will be called from a post-deploy migration, and will enqueue the background jobs to copy the data. This new helper method also has a companion method cleanup_partitioning_data_migration to be called on migration rollback, which can be used to cleanup the bookkeeping records associated with the background migration.

Also add a new migration to enqueue the backfill migration for audit_events for self-managed installations only, since the original migration in !36298 (merged) has already been merged, and should be deployed to production in the next auto-deploy.

Migration Output

up

rails db:migrate:up VERSION=20200722202318
== 20200722202318 BackfillPartitionedAuditEvents: migrating ===================
-- transaction_open?()
   -> 0.0000s
== 20200722202318 BackfillPartitionedAuditEvents: migrated (0.0464s) ==========

down

rails db:migrate:down VERSION=20200722202318
== 20200722202318 BackfillPartitionedAuditEvents: reverting ===================
== 20200722202318 BackfillPartitionedAuditEvents: reverted (0.0142s) ==========

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done