Having tox call tox is a bit weird, but the alternatives are:
 - duplication of the test command, which is a bit sad
 - replacing all the positive factors with conjunction of negative factors, e.g.
   `core` -> `!db-!server`, which makes the logic painful to follow

One day, tox will have environment aliases which will make this horror moot :-)

(Idea pulled from a comment in https://github.com/tox-dev/tox/issues/427)

The current tests depend on order of execution: if the main tests run before the
db tests, the addition of extra subcommands makes them fail.

Makes it easier to save/restore it in test fixtures.

This requires some more stub-missing entries declared in mypy.ini to pass OK.

swh.storage raises TypeErrors when type checking of incoming objects fails. We
need to make sure that these go through the RPC layer unchanged.

When run under a systemd service, the default stop command is to kill the
process; By default, Python doesn't trap sigterm and terminates the process
immediately, so even finally blocks don't run.

This traps SIGTERM and SIGINT (^C) signals and raises an exception, allowing the
process to exit in an orderly fashion.

for improved readability and control flow understandability

to that end, refactor HTTP status checking logic so that it is reused in
various places

This should allow us to stop playing whack-a-mole with logging configuration
between Celery workers (where the logging configuration is hard-coded in our
initialization routines) and CLI tools (where we only have the log-level knob).

This is useful to document the interaction between options

As mentioned by @anlambert in D2264.

make codespell happy

These values haven't changed since the types have been introduced to PostgreSQL:

https://archive.softwareheritage.org/browse/revision/d31084e9d1118b25fd16580d9d8c2924b5740dff/?path=src/backend/catalog/pg_type.h#L95
https://archive.softwareheritage.org/browse/revision/d31084e9d1118b25fd16580d9d8c2924b5740dff/?path=src/backend/catalog/pg_type.h#L200

This is an issue when swh.model is installed but not dulwich: swh.model.cli
imports dulwich unconditionally, so /usr/bin/swh fails for all subcommands
instead of just ignoring the issue.

When the simplejson module is present in the Phython environment, requests will
use it to decode json but a call to response.json(cls=...) will raise an exception
as the arguments accepted by JSONDecoder are inconsistent between the standard library
json and simplejson (more details here: https://github.com/psf/requests/issues/4842).

So ensure to use standard json module for decoding response texts.

For http requests, data is looked up within the http_<hostname> folder.

This uses both

- the `client` test fixture (from pytest-flask) to allow to easily call
  RPCServerApp based application methods,
- a `requests` Adapter class to make the RPCClient based proxy route the
  HTTP requests directly to the RPCServerApp test client above, without
  the need for a running HTTP server.

This adapter overload the `send()` method to call the Flake test app open()
method (instead of doing a real network connection), and convert the
wertzeug based Response object into a `requests` one.

Also add a few tests for the RPC client/server communication provided in
swh.core.api via RPCServerApp and RPCClient classes.

The json decoder was broken on py35, as is used to expect a str object and
not a bytes one. For now, we encode the bytes one using utf-8.

This could/should be reverted as soon as we drop support for py35.

aka. SWHServerAPIApp, MetaSWHRemoteAPI and SWHRemoteAPI.

using pytest-flask for test_rpc_server.py

defaults to calling the backend_class constructor.

this later depends on the presence of an 'app' fixture. See
pytest_flask.plugin._monkeypatch_response_class() fixture for details.