Store abuse report labels separate from project/group labels

Context

This MR implements a part of https://gitlab.com/gitlab-org/gitlab/-/issues/430957+ and is MR no. 3 of 3:

1. Move base label behavior to a concern
2. Create AbuseReportLabelType GraphQL type
3. Store abuse report labels separate from project/group labels - 👈🏼 YOU ARE HERE

Gist of https://gitlab.com/gitlab-org/gitlab/-/issues/430957+

Abuse report labels are currently implemented as Labels and stored in labels DB table. Since these labels are for abuse reports they do not have a project_id or a group_id and should be under gitlab_main_clusterwide schema (labels is under gitlab_main_cell).

The goal is to introduce a separate model and database table for abuse report labels so that both labels and abuse report labels features are compatible with Cells 1.0.

What does this MR do and why?

This MR introduces AntiAbuse::Reports::Label and AntiAbuse::Reports::LabelLink models backed by abuse_report_labels and abuse_report_label_links DB tables. It also updates the label_links and labels association of AbuseReport to use these new models as follows:

Before

erDiagram
    AbuseReport ||--o{ LabelLink : has_many
    Label ||--o{ LabelLink : has_many
    Label {
        bigint group_id
        bigint project_id
    }

After

erDiagram
    AbuseReport ||--o{ "AntiAbuse::Reports::LabelLink": has_many
    "AntiAbuse::Reports::Label" ||--o{ "AntiAbuse::Reports::LabelLink" : has_many

Finally, Admin::AbuseReportLabel < Label model is removed and all references to it are updated to use the new AntiAbuse::Reports::Label model so abuse report labels records go to abuse_report_labels table.

Questions

1. Do we need to migrate any abuse report label data from labels to abuse_report_labels?

   No. The feature is currently not actively used by T&S and is behind a disabled feature flag. There is one abuse report record created in labels table in production that was created for testing and is planned to be deleted through a change request.

2. What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on?

   Abuse report labels will be used by T&S team (instance admins) in Gitlab.com. There is no limit but with normal use we expect at most a few hundred (overestimate) records in this table.

3. How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year? Under what circumstances are rows updated? What assumptions are these based on?

   We expect labels to be created in bulk or a few at a time and updated rarely (maybe update description, title, color). Reads will happen only when visiting the abuse reports list and abuse report show page.

4. Based on the anticipated data volume and access patterns, does the new table pose an availability risk to GitLab.com or self-managed instances?

   No.

5. Does the proposed design scale to support the needs of GitLab.com and self-managed customers?

   Yes.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screen_Recording_2024-10-17_at_11.41.24_AM

How to set up and validate locally

1. In rails console, enable the feature flag

   > Feature.enable(:abuse_report_labels)

2. Login with an admin user (root)
3. Go to abuse reports page (http://localhost:3000/admin/abuse_reports) and click on any abuse report
4. Validate that creating, searching, adding, and removing labels to the abuse report works (see screencast above).