Add Users::GhostUserMigration model

What does this MR do and why?

Introduces a new model for tracking users under deletion that needs their associated records migrated to the ghost user. This will be used by a cron job doing interruptible batched migration / deletion of users and associated records with limited execution time.

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/366655

Migration output

up

$ rake db:migrate:up VERSION=20220726171440
main: == 20220726171440 CreateGhostUserMigrations: migrating ========================
main: -- create_table(:ghost_user_migrations, {:id=>false})
main:    -> 0.0084s
main: == 20220726171440 CreateGhostUserMigrations: migrated (0.0087s) ===============

$ rake db:migrate:up:main VERSION=20220726171450
main: == 20220726171450 AddUserFkToGhostUserMigrations: migrating ===================
main: -- transaction_open?()
main:    -> 0.0000s
main: -- foreign_keys(:ghost_user_migrations)
main:    -> 0.0057s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- execute("ALTER TABLE ghost_user_migrations\nADD CONSTRAINT fk_202e642a2f\nFOREIGN KEY (user_id)\nREFERENCES users (id)\nON DELETE CASCADE\nNOT VALID;\n")
main:    -> 0.0027s
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002s
main: -- execute("ALTER TABLE ghost_user_migrations VALIDATE CONSTRAINT fk_202e642a2f;")
main:    -> 0.0064s
main: -- execute("RESET statement_timeout")
main:    -> 0.0002s
main: == 20220726171450 AddUserFkToGhostUserMigrations: migrated (0.0220s) ==========

$ rake db:migrate:up:main VERSION=20220726171460
main: == 20220726171460 AddInitiatorUserFkToGhostUserMigrations: migrating ==========
main: -- transaction_open?()
main:    -> 0.0000s
main: -- foreign_keys(:ghost_user_migrations)
main:    -> 0.0057s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- execute("ALTER TABLE ghost_user_migrations\nADD CONSTRAINT fk_3eb642a4cb\nFOREIGN KEY (initiator_user_id)\nREFERENCES users (id)\nON DELETE SET NULL\nNOT VALID;\n")
main:    -> 0.0015s
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002s
main: -- execute("ALTER TABLE ghost_user_migrations VALIDATE CONSTRAINT fk_3eb642a4cb;")
main:    -> 0.0019s
main: -- execute("RESET statement_timeout")
main:    -> 0.0003s
main: == 20220726171460 AddInitiatorUserFkToGhostUserMigrations: migrated (0.0152s) =

down

$ rake db:migrate:down VERSION=20220726171440
main: == 20220726171440 CreateGhostUserMigrations: reverting ========================
main: -- drop_table(:ghost_user_migrations, {})
main:    -> 0.0043s
main: == 20220726171440 CreateGhostUserMigrations: reverted (0.0056s) ===============


$ rake db:migrate:down:main VERSION=20220726171450
main: == 20220726171450 AddUserFkToGhostUserMigrations: reverting ===================
main: -- transaction_open?()
main:    -> 0.0000s
main: -- remove_foreign_key(:ghost_user_migrations, {:column=>:user_id})
main:    -> 0.0042s
main: == 20220726171450 AddUserFkToGhostUserMigrations: reverted (0.0094s) ==========

$ rake db:migrate:down:main VERSION=20220726171460
main: == 20220726171460 AddInitiatorUserFkToGhostUserMigrations: reverting ==========
main: -- transaction_open?()
main:    -> 0.0000s
main: -- remove_foreign_key(:ghost_user_migrations, {:column=>:initiator_user_id})
main:    -> 0.0068s
main: == 20220726171460 AddInitiatorUserFkToGhostUserMigrations: reverted (0.0124s) =

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.