Add post deployment migration for cleanup policies

☎ Context

In !61983 (merged), we created a background migration to disable all enabled cleanup policies for projects that don't have any container registry image.

This is done for ~performance reasons: we have a database index referencing all the enabled policies. Background jobs that process cleanup policies use that index extensively to locate and order the container registry image to cleanup. See #330315 (closed).

The background migration was properly executed except for 3 jobs which account for ~90 000 policies on gitlab.com.

I choose to not re-schedule the background migration but have a simpler post deployment migration for those left overs.

In the future, we will update an existing cron job to take care of those policies on a recurrent basis: !62461 (merged). documentation has been updated there.

🤔 What does this MR do?

• Add a post deploy migration that will disable enabled policies linked to no container registry images.
• Add the related specs.

📸 Screenshots (strongly suggested)

n / a

📏 Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• [-] I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• [-] I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• [-] I have tested this MR in all supported browsers, or it's not needed.
• [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

💽 Database review

Up

$ rails db:migrate
== 20210610141711 DisableExpirationPoliciesLinkedToNoContainerImages: migrating 
-- execute("        WITH batched_relation AS MATERIALIZED (SELECT \"container_expiration_policies\".* FROM \"container_expiration_policies\" WHERE \"container_expiration_policies\".\"enabled\" = TRUE AND \"container_expiration_policies\".\"project_id\" >= 76 LIMIT 1000)\n        UPDATE container_expiration_policies\n        SET enabled = FALSE\n        FROM batched_relation\n        WHERE container_expiration_policies.project_id = batched_relation.project_id\n        AND NOT EXISTS (SELECT 1 FROM \"container_repositories\" WHERE container_repositories.project_id = container_expiration_policies.project_id)\n")
   -> 0.0072s
== 20210610141711 DisableExpirationPoliciesLinkedToNoContainerImages: migrated (0.0274s) 

Down

$ rails db:rollback
== 20210610141711 DisableExpirationPoliciesLinkedToNoContainerImages: reverting 
== 20210610141711 DisableExpirationPoliciesLinkedToNoContainerImages: reverted (0.0000s) 

Queries / Explain plans

• Min / Max for each_batch: !63841 (comment 598808271)
• Update: !63841 (comment 598809506)