Flag if test report is generated using legacy requirement yml

What does this MR do and why?

We are in the process of deprecating the legacy requirement IID in favour of work item IID (see #382139 (closed) and &9203). As part of this effort we now support work items of type Requirement to be referenced by IID from test cases 👉 !105822 (merged) and #329435 (closed)

When legacy requirement IIDs are referenced in a test report (that is, when the yml contains legacy requirement iid references), we need to flag that the test report yml needs to be updated to use the work item IID instead. It means users using legacy Requirements can know that they have to make adjustments to the yml.

Future MRs:

• Exposing uses_legacy_iid in the API and/or serialisers
• The frontend and UX part (actually alerting users)

Migration

up

$ be rake db:migrate
main: == 20230110031131 AddUsesLegacyIidToTestReports: migrating ====================
main: -- add_column(:requirements_management_test_reports, :uses_legacy_iid, :boolean, {:null=>false, :default=>true})
main:    -> 0.0413s
main: == 20230110031131 AddUsesLegacyIidToTestReports: migrated (0.0423s) ===========

ci: == 20230110031131 AddUsesLegacyIidToTestReports: migrating ====================
ci: -- add_column(:requirements_management_test_reports, :uses_legacy_iid, :boolean, {:null=>false, :default=>true})
ci:    -> 0.0056s
ci: == 20230110031131 AddUsesLegacyIidToTestReports: migrated (0.0110s) ===========

down

$ be rake db:migrate:down:main VERSION=20230110031131
main: == 20230110031131 AddUsesLegacyIidToTestReports: reverting ====================
main: -- remove_column(:requirements_management_test_reports, :uses_legacy_iid, :boolean, {:null=>false, :default=>true})
main:    -> 0.0045s
main: == 20230110031131 AddUsesLegacyIidToTestReports: reverted (0.0437s) ===========

$ be rake db:migrate:down:ci VERSION=20230110031131
ci: == 20230110031131 AddUsesLegacyIidToTestReports: reverting ====================
ci: -- remove_column(:requirements_management_test_reports, :uses_legacy_iid, :boolean, {:null=>false, :default=>true})
ci:    -> 0.0040s
ci: == 20230110031131 AddUsesLegacyIidToTestReports: reverted (0.0153s) ===========

How to set up and validate locally

1. Create a couple of requirements in your project. Use the following GraphQL query in GraphiQL:

query { 
  project(fullPath: "flightjs/Flight") {
    requirements {
      nodes {
        iid
        workItemIid
        title
      }
    }
  }
}

2. Set up a runner (shell one is fine) following https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/runner.md

Work item IID (non-legacy)

3. In a project, set up the following .gitlab-ci.yml file:

requirements_confirmation:
  when: manual
  allow_failure: false
  script:
    - mkdir tmp
    - echo "{\"4\":\"failed\", \"6\":\"passed\"}" > tmp/requirements_v2.json
  artifacts:
    reports:
      requirements_v2: tmp/requirements_v2.json

(replace the 4 and 6 with work_item_iid of your requirements you made in step 1).

4. Trigger the job defined above in the project pipelines section
5. In a rails console, check the last test report and check its uses_legacy_iid value.

> RequirementsManagement::TestReport.last.uses_legacy_iid
# => false

Legacy requirement IID

1. Follow the directions on https://docs.gitlab.com/ee/user/project/requirements/#allow-requirements-to-be-satisfied-from-a-ci-job using the following yml (replace the 1 and 2 with the iid - not work_item_iid - for the requirements you created in step 1):

requirements_confirmation:
  when: manual
  allow_failure: false
  script:
    - mkdir tmp
    - echo "{\"1\":\"passed\", \"2\":\"failed\"}" > tmp/requirements.json
  artifacts:
    reports:
      requirements: tmp/requirements.json

2. In a rails console, check the last test report and check its uses_legacy_iid value.

> RequirementsManagement::TestReport.last.uses_legacy_iid
# => true

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