The Cargo extension currently uses a single database connection to
access and manage its database tables, managed entirely by CargoUtils
without going through the usual MW DBAL layers. This ipso facto
precludes the use of a proper primary - replica setup, as this
connection must allow database writes. We want to do just that, so that
we can offload read queries to replicas where possible and avoid putting
undue load on the primary DB in an active-active world. So, first make
it possible for Cargo to utilize replicas at all by factoring out its DB
connection management logic into a new class that can be optionally
configured to use the MW DBAL to obtain DB connections while keeping
backwards compatibility with the existing setup.

With this done, the main source of primary DB access in Cargo - the
cargo_query parser function, which often gets run in case of parser
cache misses - can actually be switched to use a replica, as it does not
really need to read from the primary. However, one may imagine a case
where it is necessary for a query to lead the latest and greatest data
from the primary, e.g. on a page that stores some data via cargo_store
then queries some of that data via cargo_query further down the line.
Sidestep this by leveraging MW's hasOrMadeRecentPrimaryChanges() helper
to always return a primary DB connection irrespective of the caller, if
writes have been detected on the configured Cargo LB.

This code has not yet been actually tested - I am submitting this to
gather opinions and suggestions.

Change-Id: I5ed6661f46be257d1ea6b194aaccbbc5b02c406a

…argoAttach, CargoDeclare and CargoPageValues

Some of the actions are still using PRIMARY DB connection during the Read requests, and therefore we should replace them with use of the proper REPLICA DB. All of those cases are simple and shouldn't yield any errors when PRIMARY DB is not used to query the results.
Also, mark CargoRecreateTablesAPI as writing API to minimise noise from transaction profile.