Follow-up from "Add existence checks around todos migration to ensure it is idempotent"

The following discussion from gitlab-ce!20543 should be addressed:

• @nolith started a discussion: (+3 comments)

  @stanhu I'm not sure about this.

  If we follow what you suggested in https://gitlab.com/gitlab-com/infrastructure/issues/4555#note_87200871 we will be able to deploy immediately, picking this requires waiting for the 12h QA windows for RC7 on staging, and we also have gcp_migration failover test tomorrow.

  stanhu

  Right, I think we'll want this regardless of what we do since this migration can fail partway through.

  nolith

  yes, good point.

  @yorickpeterse was also concerned about the content of the down method gitlab-com/infrastructure#4555

  stanhu

  Yeah, that is a separate issue indeed.

@yorickpeterse said

The rollback procedure is also problematic, as it performs operations that will lock the entire table (e.g. removing the index), and heavy writes (removing all todos with a NULL project ID, without any batching).