for now, managing the dbversion table (storing the db schema upgrade
history) is partially the responsibility of the swh modules implementing
a datastore (swh-storage etc.), and the actual swh module was not stored
in the database.
This adds support for both the dbversion and dbmodule tables management
in swh.core.db.
The `swh db init` command now creates both these tables and initialise
their values if possible.
For this, it introduces a new common "API" for swh.core.db based datastores:
- a swh module implementing a datastore is expected to have a
`get_datastore` function in its top namespace; this function is
typically the actual `get_storage`, `get_scheduler` etc. functions
- this factory function is expected to use the "postgresql" cls for the
datastore based on swh.core.db,
- the datastore instance (eg. instance of the swh.storage.postgresql.Storage
class) is expected to have a `get_current_version()` method (returning
an int).
This revision also provides a new `swh db version` command displaying
the current (code) version (if avalable), the db version (possibly the whole
version history) and flavor (if any) for the datastore given as argument.
It should be bacward compatible with eisting swh datastore modules (i.e.
not adapter to this new API).
Also refactor the mock_package_sql fixture to allow multiple sql script set
will be used to implement several test scenarios in following commits.
Also rename existing sql scripts with a "legit" numbering scheme.
Depends on D7061
Related to T3894