We've had a few examples recently of this recently and it might help
guide people in the right direction by adding these to the docs.

Related to: https://gitlab.com/gitlab-org/technical-writing/-/issues/492

This change keeps track of spec files which are failing the cross
database modification check. The change also enables the check globally.

This uses `#annotate` to indicate that given relation is exempt
from cross-join verification check.

This documents the prior and new syntax for config/database.yml
and a list of supported keys, with a syntax description.

Add example of when it can be used and explain the risks and the reason
we need to examine each usage before just adding it.

Also remove the summary section as it was already getting out of
sync.

This uses a filename based approach to allowlist spec files

Add documentation about cross-database joins detection

Suggestions from tech writer.

This method didn't actually need to join. `preload` is sufficient in
this case. This commit also introduces documentation for this specific
case in case others run into a similar problem in future.

This method can be passed a block and we can validate that no SQL query
in that code block attempts to join across ci/main databases. This is
useful in the intermediate time while we attempt to fix many small
issues until we enable this as the default in all RSpec tests.

This adds a support for `schema_migrations_path`
in a similar way to `migrations_paths`
for managing database configs.

Add a new Ci::ApplicationRecord that all CI models should inherit from.
This also replaces the usage of the previous Gitlab::Ci::Model.

This is a list of patterns we've seen so far to fix queries that will no
longer be allowed when we move `ci_*` tables to a separate database.

"primary" should be reserved for replication contexts. So we can talk
about main primary, main replica, ci primary, ci replica databases.

We have accidentally caused all CI models to use Ci::ApplicationRecord
when we only want Ci::InstanceVariable to do so