Add NOT NULL constraint to required_code_owners_sections

What does this MR do and why?

Adds NOT NULL constraint on sharding key column protected_branch_project_id and protected_branch_namespace_id on table: required_code_owners_sections.

This merge request is the last step towards transforming the desired sharding key into a sharding key.

This involves the following changes:

• Adding a not null constraint for the sharding key columns (protected_branch_project_id and protected_branch_namespace_id).
• Setting protected_branch_project_id and protected_branch_namespace_id as sharding_key of required_code_owners_sections.

We are skipping model-level validations when adding NOT NULL for now: !189213 (comment 2480466972)

The backfilling migrations were finished and finalized:

• https://gitlab.com/gitlab-org/gitlab/blob/15927dcbabd7c8884bc179c0210d9da260d2a7cd/db/docs/batched_background_migrations/backfill_required_code_owners_sections_protected_branch_project_id.yml
• https://gitlab.com/gitlab-org/gitlab/blob/5c2e9011677716b2f1f37e1c295f8078d09b9a08/db/docs/batched_background_migrations/backfill_required_code_owners_sections_protected_branch_namespace_id.yml

References

• !189213 (comment 2480466972)
• https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables
• https://docs.gitlab.com/development/database/not_null_constraints/

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.