Correct inconsistency between namespace_id and project_namespace_id on design management tables

What does this MR do and why?

This MR updates the design management tables to use the corresponding project's project.project_namespace_id as the sharding key, as opposed to the previous implementation which used project.namespace_id.

• 2 of these tables (design_management_designs and design_management_repositories) have a foreign key to the corresponding schedule
• design_management_designs_versions and design_user_mentions both fetch their sharding key from the design_management_designs table
• design_management_repository_states fetches its sharding key from design_management_repositories

In order prevent needing to wait 2 required stops to correct the sharding key on all of these tables (i.e. one to finalise design_management_designs / design_management_repositories, and another to finalise design_management_designs_versions, design_user_mentions and design_management_repository_states), the background migration for the parent tables also updates the namespace_id for the child tables, once it's namespace_id has been adjusted.

References

• #557010 (closed)

Screenshots or screen recordings

• Not Provided

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.

Related to #557010 (closed)