Workspace config_version 2 migration

What does this MR do and why?

Workspace config_version 2 migration

• We ask for a full reconciliation
• We expect close to zero migration on gitlab.com and a handful for self-managed.

Related to #424215 (closed)

Blocked by: Backfill existing workspaces with PATs (!131516 - merged)

Migration output

bin/rails db:migrate:up:main VERSION=20230910120000  RAILS_ENV=development
main: == [advisory_lock_connection] object_id: 226800, pg_backend_pid: 2758372
main: == [advisory_lock_connection] object_id: 226800, pg_backend_pid: 2758372

$ bin/rails db:migrate:down:main VERSION=20230910120000  RAILS_ENV=development
main: == [advisory_lock_connection] object_id: 226780, pg_backend_pid: 2758706
main: == 20230910120000 QueueUpdateWorkspacesConfigVersion: reverting ===============
main: == 20230910120000 QueueUpdateWorkspacesConfigVersion: reverted (0.0150s) ======
main: == [advisory_lock_connection] object_id: 226780, pg_backend_pid: 2758706

Query plans

The update query for the full data on gitlabdotcom. We expect no data to process.

UPDATE "workspaces"  SET "config_version" = 2, "force_full_reconciliation" = true  WHERE "workspaces"."id" BETWEEN 1 AND 240 AND "workspaces"."config_version" = 1 AND "workspaces"."actual_state" != 'Terminating' AND "workspaces"."id" >= 1

Query plan: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/22144/commands/71551

That's for 200 rows range, which is 10x for the 20 sub batch size. The query can be improved, but since we have a handful of data in most instances, i think we don't need to.

How to set up and validate locally

Running the specs would give an idea how workspace rows are migrated.

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.