Labels sharding_key handles template labels

What does this MR do and why?

We can have labels that don't belong to a group or project, and these will be used as default labels for when a new project is created. For these, we need the sharding_key to be organization_id

This MR also backfills template records (no group or project associated). Only 12 are found in .com and they are not visible through the UI because they have template=false set. But we still clean those up and we probably have more of those in other self-hosted instances

Note

This MR introduces a NOT VALID multiple parent constraint, but there's no simple way to validate that constraint as I found that we have multiple (older) records that have both a project_id and group_id set. For that reason, the unique index in the DB didn't enforce uniqueness of title across some projects (two partial indexes WHERE group_id IS NULL or WHERE project_id IS NULL). So, it will probably take additional effort to clean those up (might even require renaming some labels so we can validate the constraint)

Query plans

Index template labels scoped to organization

https://console.postgres.ai/gitlab/gitlab-production-main/sessions/42188/commands/129338

SELECT 
  "labels".* 
FROM 
  "labels" 
WHERE 
  "labels"."organization_id" = 1 
  AND "labels"."template" = TRUE 
  AND (
    "labels"."type" = 'Label' 
    OR "labels"."type" IS NULL
  ) 
ORDER BY 
  "labels"."title" ASC 
LIMIT 
  20 OFFSET 0

MR acceptance checklist

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

Related to #545051 (closed)