Update delayed_project_removal to NULL for UserNamespaces

What does this MR do and why?

• We have a couple of user namespaces that have delayed_project_removal set as false in the namespace_settings table. As a result of this, even though delayed deletion would be enabled at the instance level, these user namespaces still have delayed deletion disabled.
• In this MR we've set "namespace_settings"."delayed_project_removal" column as nil for these namespaces so that delayed deletion works for all the user namespaces and does not have any inconsistencies.
• Affecting 8303587 rows.

Database

Entire migration takes ~17mins on database lab without batching - https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/10749/commands/38780

Migration Up

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/10772/commands/38832

bundle exec rails db:migrate
main: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: migrating
main: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: migrated (0.0623s)

ci: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: migrating
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: migrated (0.0002s)

Migration Down

bundle exec rails db:rollback:ci && bundle exec rails db:rollback:main
ci: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: reverting
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: reverted (0.0001s)

main: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: reverting
main: == 20220627152642 QueueUpdateDelayedProjectRemovalToNullForUserNamespace: reverted (0.0322s)

Screenshots or screen recordings

How to set up and validate locally

1. Before running the background migration set delayed_project_removal a few user namespace settings to false so that we have data similar to production by running the following command in rails console.

user_namespace_settings = user_namespace_settings = NamespaceSetting.joins(:namespace).where("namespaces.type" => 'User').limit(2)
user_namespace_settings.update_all(delayed_project_removal: false)

2. Set delayed_project_removal a few group namespace settings to false by running the following command in rails console.

group_namespace_settings = user_namespace_settings = NamespaceSetting.joins(:namespace).where("namespaces.type" => 'Group').limit(2)
group_namespace_settings.update_all(delayed_project_removal: false)

3. Queue background migration by running the following

bundle exec rails db:migrate

4. Verify that the batched background migration UpdateDelayedProjectRemovalToNullForUserNamespaces is created by running the following in rails console

Gitlab::Database::BackgroundMigration::BatchedMigration.find_by_job_class_name('UpdateDelayedProjectRemovalToNullForUserNamespaces')

5. Visit the background_migrations admin dashboard and verify that the background migration is completed successfully.
6. Verify that for the user namespaces delayed_project_removal is set to nil whereas for group namespaces nothing is updated.
   1. Run user_namespace_settings.reload and verify that delayed_project_removal is set to nil
   2. Run group_namespace_settings.reload and verify that delayed_project_removal is not udpated.

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.

Relates to #366302 (closed)