Add sharding keys for system_access

Add sharding keys for feature category system_access.

These tables have been identified as cell local tables.

All cell local tables require a sharding key.

A sharding key has been automatically selected for these tables. The sharding key was chosen because it is a NOT NULL column referencing either projects or namespaces.

Additionally, gitlab_schema has been set to gitlab_main_cell for any tables that 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 groupauthentication to review these changes. Please confirm that each table should indeed be cell local, and that the selected column is an appropriate sharding key. 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 @DylanGriffith.

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::DetermineShardingKeyFeatureCategory keep.

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