Add "next" desired sharding keys for feature category `code_review_workflow`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys, and we are labelling them as "next" because:

- this table does not have any belongs_to: relationship to a table that itself has a `NOT NULL` sharding key.
- however, this table has at least one belongs_to: relationship to a table that has a `desired sharding` key, that is yet to be backfilled.
- We work on the assumption that the desired sharding key on this parent association will be eventually backfilled, and when that is completed, the child table can inturn backfill from that parent association.

We use `awaiting_backfill_on_parent: true` to distinguish between "next" desired sharding keys and the normal desired sharding keys.

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](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

Reviewer, 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.

You can see the POC MR of this approach [here](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145135)

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)
using the Keeps::DetermineNextDesiredShardingKeyFeatureCategory keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other