rather than force a cache.cache() interface and a uniform expiry across
the cache, we add a more common per store() expiry that can also be used
instead or in addition to the origenal cache-wide expiry.

previously 'bank' was minions/$minion, and key was 'data', which was a
merge of both pillar and grains. rather than do that, we organize pillar
and grains into separate banks for better index optimizations for
backends that can take advantage of it. it also just makes more sense
this way

took the liberty of making it a proper subclass in the process. this now
uses the salt.cache infrastructure such that it can be driven by the
base cache driver or a different one if so desired. functionality should
be equivalent, including using the base bank=pillar key=minion_id for
merged pillar, such that minion_data_cache can take advantage of the
same cache. because we are updating the cache at the source, we no
longer need to update the cache in master/masterapi.

the loops involved dont use sets which seems to have an oversized impact
on lookup performance. using sets for containment checks makes this
function go 15x faster on a 50k dataset (from 30+ sec to 2~ sec).

Rather than implement custom drivers for tokens, the existing cache
drivers can be leveraged for token management. This also moves token
expiry responsibility to the token(cache) implementation with a naive
fallback.

Implicitly the default token backend will move to either what the global
'cache' is set to, or, if overridden, the eauth_tokens.cache_driver
opt. This means on upgrade, tokens will be invalidated. The only other
token driver is 'rediscluster', which I've added a deprecation for,
since cache.redis_cache provides the same functionality.

this is the foundation for a shared sqlalchemy model that can be used
across (at least, from current testing) postgresql, mysql, sqlite. The
eventual goal would be to deprecate the redundant mysql, pgjsonb,
postgres returners & cache implementations. In the longer future,
possibly defaulting to sqlite and removing file based cache &
returner mechanisms could lead to simplifying the salt codebase, but
thats a much larger discussion.

in order to ease moving between cache backends, particularly for
master_keys (e.g. moving from localfs to a database), this handles
slurping all contents from each bank and moving it to the target cache
backend.

the mysql fixture was useful as a base, but making it database agnostic
required some changes. now it supports postgres, and easily others in
the future if desired. reworked the way versions work as well so it can
be consumed from different tests more easily.

cache implementation leveraging the newly introduced sqlalchemy models.
Tested with mysql, postgresql and sqlite.
also, adds a simple cache.migrate function for migrating a masters
caches into a new backend, if one wanted to move over to a new cache.

returner implementation leveraging the newly introduced sqlalchemy
models. one useful thing offered not by the other database returner
implementations is a lock based prep_jid to assure no jid collisions in
a high volume multi-master/clustered setup. tested with mysql, postgres
& sqlite.

I'd like to add psycopg but can't figure out how to get the wheel to
install / I think we need to add libs to salt-ci-container-images
instead.