Backfill version field batch migration

What does this MR do and why?

Backfill the vs_code_settings table's version field with a default value that varies across setting types.

Why?

We added the version field after introducing the vs_code_settings table without a not null constraint. This merge request is the first step in enforcing a not null constraint as described in the NOT NULL constraint guidelines https://docs.gitlab.com/ee/development/database/not_null_constraints.html.

Where does this default values come from?

These default values defined by the VSCode open source project.

1. settings
2. extensions
3. globalState
4. keybindings
5. snippets
6. tasks
7. profiles

How to set up and validate locally

1. Create one or more vs_code_settings records with a version set to nil or 0 .
2. Run the migration introduced by this MR.
3. The version field should have the correct default value after running the migration.

Migration details

Queries and execution plan

-- Query 1: First query to select rows for migration. 
SELECT
    "vs_code_settings"."id"
FROM
    "vs_code_settings"
WHERE
    "vs_code_settings"."id" BETWEEN 20 AND 25
    AND ("vs_code_settings"."version" = 0
        OR "vs_code_settings"."version" IS NULL)
    AND "vs_code_settings"."id" >= 20
ORDER BY
    "vs_code_settings"."id" ASC
LIMIT 1 OFFSET 100

-- Query 1: Execution plan
Limit  (cost=3.15..6.18 rows=1 width=8) (actual time=0.935..0.937 rows=0 loops=1)
   Buffers: shared hit=9 read=1
   I/O Timings: read=0.876 write=0.000
   ->  Index Scan using vs_code_settings_pkey on public.vs_code_settings  (cost=0.13..3.15 rows=1 width=8) (actual time=0.933..0.934 rows=0 loops=1)
         Index Cond: ((vs_code_settings.id >= 20) AND (vs_code_settings.id <= 25) AND (vs_code_settings.id >= 20))
         Filter: ((vs_code_settings.version = 0) OR (vs_code_settings.version IS NULL))
         Rows Removed by Filter: 0
         Buffers: shared hit=9 read=1
         I/O Timings: read=0.876 write=0.000

-- Query 2: An upsert operation that updates every record with a nil uuid
INSERT INTO "vs_code_settings" ("id", "user_id", "created_at", "updated_at", "setting_type", "content", "uuid", "version")
    VALUES (20, 1, '2023-11-22 11:40:32.627558', '2023-12-12 09:50:56.747793', 'keybindings', '{"mac":"[]"}', '1f385ab6-2ce9-4441-8c73-55da36837e2b', 2)
ON CONFLICT ("id")
    DO UPDATE SET
        "user_id" = excluded."user_id", "created_at" = excluded."created_at", "updated_at" = excluded."updated_at", "setting_type" = excluded."setting_type", "content" = excluded."content", "uuid" = excluded."uuid", "version" = excluded."version"
    RETURNING
        "id"
-- Query 2: Execution plan
ModifyTable on public.vs_code_settings  (cost=0.00..0.01 rows=1 width=116) (actual time=1.808..1.810 rows=1 loops=1)  
   Buffers: shared hit=24 read=3 dirtied=5 written=3  
   I/O Timings: read=1.054 write=0.000  
   ->  Result  (cost=0.00..0.01 rows=1 width=116) (actual time=0.002..0.002 rows=1 loops=1)  
         I/O Timings: read=0.000 write=0.000  

How big is the table on gitlab.com, any duration estimation?

The vs_code_settings table is still not used by any features in gitlab.com, therefore it should have a minimal number of rows. Even though I estimate that the time to perform this migration is minimal, I implemented a BatchedBackground migration given the lack of knowledge about other instances.

Is this feature also available on self managed?

Yes, this feature is also available on self-managed instances, however, just like gitlabdotcom, this database table isn't used by any feature yet.

Will this run EE or on core?

This migration will run on Core. It is for the Web IDE which is available in all product tiers.

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 #432992 (closed)