This was causing too many false positives which are not representative
of code that is actually running in production. It is very common in
tests to build a tree of related objects in FactoryBot and save them all
in one go with `save!` (this is the default behaviour in FactoryBot for
association building). When this is done it creates an outer transaction
and saves all the models within the context of this transaction. If 2 of
the models belong in a different `gitlab_schema` (database) then this
triggers our cross-database modification detection logic. While there is
a chance that this could be indicative of problems in our model code
(eg. `before_save` and so on) it is more often than not just a problem
with how our factories are building a relation tree.

A simple example is included as an RSpec test here where we create a
`ci_runner` and `project` (which in turn creates a `user`) all in one
go. This is convenient in tests but it is never going to happen in real
production code as there is no way to create a project at the same time
as creating a runner (let alone user). You would always have a project
and a user and then later create the runner for that project.

Our PreventCrossDatabaseModification detection logic is designed to find
places in our code where we are writing to 2 different databases in the
context of a transaction of one of those databases. This was introduced
because we are decomposing our database into separate databases.
Specifically we are moving all CI tables to a separate CI database. It's
important that we find and fix any places in our code where we are
opening a transaction and expecting all transaction semantics (ie.
rollbacks) to apply to all database queries within that context. When
you have 2 databases there may be places where we are only rolling back
some of the queries in that transaction which could lead to data
inconsistency bugs. As such we need to detect and restructure such
transactions so that each case is properly handled.