Add desired sharding keys for geo_replication

Add desired sharding keys for feature category geo_replication.

These tables have been identified as a cell local tables. All cell local tables require a sharding key or a desired sharding key

A desired sharding key has been automatically selected for these tables. These keys were chosen as the desired sharding keys because the table has a :belongs_to relationship to a table that itself has a NOT NULL sharding key.

Additionally, gitlab_schema has been set to gitlab_main_cell for any tables didn't use this schema already. For these tables we have also added allow_cross_joins, allow_cross_transactions and allow_cross_foreign_keys. These will silence any existing violations, allowing the pipeline to pass without requiring further changes. In the future, we'll remove these allow_... statements and fix any violations as they arise. You can read more about this in the documentation for multiple databases

We have assigned a random backend engineer from groupgeo to review these changes.

Please confirm that:

• each of these tables can be classified as cell local
• the selected desired sharding key is appropriate
• the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger. If you have any questions or concerns, reach out to @tigerwnz or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you can use this link.

This change was generated by gitlab-housekeeper using the Keeps::DetermineDesiredShardingKeyFeatureCategory keep.

To provide feedback on your experience with gitlab-housekeeper please comment in #442003.