Draft: Update container_repositories migration_state default

⚠ DO NOT MERGE ⚠ Please wait to merge this MR. No additional changes are expected, but I will keep it in Draft until that time. We would like to roughly coordinate the merge with a production change and need to wait for a go-ahead on the container registry side before proceeding. Once this MR is approved, feel free to unassign and I will ping when it is ready to be merged.

What does this MR do and why?

We have been in the process of migrating all container repositories to the new container registry on GitLab.com. On the rails side of things, the container_repositories table uses the migration_state column to track where a given container repository is in the process (importing, aborted, skipped, ...). The default value for migration_state is default. But now all new container repositories are automatically part of the new registry, so we can update the initial value to import_done. This will help ensure that no new container repositories start the import process. We also set the default value for migration_skipped_reason: :native_import. This allows us to keep track of which container repositories reached the done state from a real import, versus which ones were created on the new registry and were never imported. This is the same state we apply when we happen to come upon a container repository in the import process that already exists in the new system: https://gitlab.com/gitlab-org/gitlab/-/blob/6977989564acc8ec6462f9a190a8f7fabb03d70a/app/models/container_repository.rb#L355.

A few notes:

• The entire system is behind a feature flag, this only effects GitLab.com.
• The migration system is not going to be used as-is for self-managed, so having these values change on self-managed will have no effect. These columns will either be reset or removed when we start the process to migrate self-managed to the new registry.
• These are model changes rather than database changes. The state machine used for migration_state will override any database defaults, so if we updated the database default for migration_state, the model will always use whatever is listed in the initial: value. Similarly, the migration_skipped_reason is an enum with a default of NULL. We are ok leaving that here. On the off chance that some records are created and the model default does not get applied, the migration system and data integrity will not be effected.

Screenshots or screen recordings

[26] pry(main)> ContainerRepository.create!(project: Project.first, name: 'foo')
=> #<ContainerRepository:0x000000016c3f0be8
 id: 7,
 project_id: 1,
 name: "foo",
 created_at: Wed, 03 Aug 2022 19:09:13.443663000 UTC +00:00,
 updated_at: Wed, 03 Aug 2022 19:09:13.443663000 UTC +00:00,
 status: nil,
 expiration_policy_started_at: nil,
 expiration_policy_cleanup_status: "cleanup_unscheduled",
 expiration_policy_completed_at: nil,
 migration_pre_import_started_at: nil,
 migration_pre_import_done_at: nil,
 migration_import_started_at: nil,
 migration_import_done_at: nil,
 migration_aborted_at: nil,
 migration_skipped_at: nil,
 migration_retries_count: 0,
 migration_skipped_reason: "native_import",
 migration_state: "import_done",
 migration_aborted_in_state: nil,
 migration_plan: nil,
 last_cleanup_deleted_tags_count: nil>

How to set up and validate locally

In a rails console, create a new container repository, the migration_state should be "import_done" and the migration_skipped_reason should be "native_import":

ContainerRepository.create!(project: Project.first, name: 'foo')

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.

Related to #352167