Preserve work_item_types old ID during ID transition

We are trying to fix the IDs of records in the work_item_types table. We need them to be 1 - 9. But, we found that this is not true in multiple instances included .com. We need this for the Cells effort.

The plan is to change the IDs and try to have the less impact as possible in the user experience. For that reason I propose preserving the old IDs in a new column so in places we take a work item type ID as input, we can find in the DB by the old value in the event of not finding it by the ID column.

We could do this for a couple releases to minimize the impact in the user experience, and then simply drop the fallback code and the old_id column. This could be documented and perhaps we can use a major version to drop the fallbacks

ID vs OLD_ID collisions

In theory we could have instances where the wrong ID value of a work_item_types record, matches the correct_id value of another record.

Example

    name     | id | correct_id
-------------+----+------------
 Issue       |  1 |          1
 Incident    |  2 |          2
 Test Case   |  3 |          3
 Requirement |  4 |          4
 Task        |  8 |          5 # Task conflicts with Epic correct_id
 Objective   |  9 |          6 # Objective conflicts with Ticket correct_id
 Key Result  | 10 |          7
 Epic        | 11 |          8
 Ticket      | 12 |          9

But, this is a very unlikely scenario since we found that the ID sequence for work_item_types records was getting increased during project imports (with the wrong issue_type) before the Task type was introduced (the first 4 were created at once so they should all be IDs 1 - 4). So conflicts could only exist in a very specific scenario where IDs actually are not 1 - 9 due to project imports, but the project import only imported 5 issue records with the wrong issue_type value. In most cases if this was a problem, I would expect records to look similar to .com as in

    id    | correct_id |    name
----------+------------+-------------
        1 |          1 | Issue
        2 |          2 | Incident
        3 |          3 | Test Case
        4 |          4 | Requirement
        5 |          5 | Task
 46657152 |          6 | Objective
 46657153 |          7 | Key Result
 91413915 |          8 | Epic
 91413916 |          9 | Ticket

Old proposal (no fallbacks)

Add work_item_types.fixed column to signal deploy completion

We are going to change the global IDs of records in the work_item_types table as part of [Cells 1.0] Default Work Item Types: Ensure wor... (&15272 - closed)

We are aware of the implications of doing this as it could be considered somewhat of a breaking change in our GQL API. But, the work items API was always released as alpha so this shouldn't be a problem there's no way around this. But, to minimize the impact of this change in multi-version deploy environments, we are adding a boolean column to the work_item_types table (fixed) which we will update in a post_deploy migration so we can signal the code that the deployment of the new version is complete and we are no longer handling mixed version deployments. With this signal we will change how to handle work item type ID inputs in the GQL API as well as exposing those IDs in the GQL WorkitemType type.

We can't tell in each instance what is the state of the records in the work_item_types table. There might be instances where they already have IDs 1 - 9 (and we know for sure for instances that were created starting with 17.5). We also know that .com has IDs far from 1 - 9 values in the range of thousands.