Create, link model classes for tables that are missing them and then run desired sharding key automation

We denote classes of tables with the class key in it's database dictionary. Example:

---
table_name: cloud_connector_access
classes:
- CloudConnector::Access

Here, CloudConnector::Access is the table backing the cloud_connector_access table.

However, currently, some tables in the app are missing a Rails model to back this table.

Here is a list of such table names and their feature categories:

[
  ["approval_group_rules_protected_branches", ["source_code_management"]],
  ["approval_group_rules_users", ["source_code_management"]],

  ["approval_merge_request_rules_approved_approvers", ["code_review_workflow"]],

  ["dast_scanner_profiles_tags", ["dynamic_application_security_testing"]],
  ["dast_site_profiles_pipelines", ["dynamic_application_security_testing"]],

  ["dingtalk_tracker_data", ["integrations"]],
  
  ["external_approval_rules_protected_branches", ["compliance_management"]],
  ["external_status_checks_protected_branches", ["compliance_management"]],

  ["issues_prometheus_alert_events", ["incident_management"]], 
  ["issues_self_managed_prometheus_alert_events", ["incident_management"]],

  ["operations_feature_flag_scopes", ["feature_flags"]],
]

These tables need to have a Rails model backing them because:

• once we have that, we can set a desired_sharding_key on these models. Setting of desired sharding keys requires a Rails model to be present for a table because we need to validate that the belongs_to association used to backfill this column actually exists and is valid.

Implementation plan:

• We will be creating issues and assigning them to the respective teams owning these tables to perform this task. They should:
  • Create a Rails model for this table.
  • Set up the belongs_to associations on this model based on the current state of columns on this table.
  • Link the class to the table using the table's db/docs/table_name.yml file, with the classes key. Example.

Once class has been added in the yml, grouptenant scale can run automations to set desired sharding keys for these tables.

PS: If the table is no longer used or is not needed, you needn't add a model, rather you can work on dropping the table altogether.

Example MR:

See !145265 (diffs)