Remove foreign key between abuse_report_user_mentions and notes

What does this MR do and why?

Remove fk_a4bd02b7df foreign key between abuse_report_user_mentions.note_id and notes(id), in a post-deployment migration.

Why

This is step 2 of 3 in dropping the dead abuse_report_user_mentions table.

• The abuse-report notes feature was abandoned. Its sibling tables were already dropped in 18.5 through 18.7, but this table was missed.
• The table also has a Cells compatibility problem: its unique index on (abuse_report_id, note_id) does not include the sharding key. Rather than fix the index on a dead table, we are dropping the table.
• Step 1 (dead code removal) merged in 19.4: !250375 (merged)
• Step 3 will remove the two remaining foreign keys and drop the table: !251541 (merged)

Context

A first attempt bundled the code removal, all three foreign key removals, and the table drop into one merge request using regular (non post-deployment) migrations: !249546 (merged)

On production-canary, the foreign key removal on notes could not acquire the ACCESS EXCLUSIVE lock it needs, because notes is a high-traffic table with continuous writes. It blocked auto-deploy close to the monthly release window, and was reverted.

This MR re-introduces the reverted migration that dropped the foreign key as a post-deployment migration. If this migration cannot get the lock, nothing breaks. Nothing depends on the foreign key being gone until step 3, so the post-deployment migration can simply be retried on a later run.

References

Tracking issue: gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#781 (closed)

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.