Related to T3079

This reverts commit f5c6e56a.

mypy needs a virtualenv with all the dependencies of the current module
installed, which is not what we do in the static-analysis stage
currently (we use tox for that). This needs more thought.

This makes setuptools-scm generate a nonsensical version number, which makes the
pip dependency resolution harder than it should be when there is a circular test
dependency (e.g. swh.scheduler > swh.lister > swh.scheduler).

Whole job takes around 40 minutes now to be fully executed so increase
build timeout to 45 minutes.

pip 20.3 just got released and set its new resolver as default.

However it does not seem stable enough yet as the pip command to install swh
dependencies now ends up executing a really long package backtracking process
that makes the swh-environment Jenkins job timeout.

Until this got sorted out by pip developers, workaround the issue by splitting
out the pip command into multiple ones (one by swh package).

Some swh components like swh-core have multiple tests directories so
prefer to invoke tests using make as it abstracts the correct pytest
command to execute.

It enables to browse code coverage report at source file level in Jenkins Web UI.

Set the value to STORE_LAST_BUILD to only keep coverage report for the last
executed build job.

Invoke yarn build-dev target to avoid duplicating script instructions
from package.json.

Remove explicit call to cypress install as it has already been performed
by the call to yarn install.

This allows to deal with naming discrepancies in debian/python/archive naming
as the swh-icinga-plugins demonstrates.

Its current build fails because of naming discrepancy, the:
- repository is named swh-icinga-plugins
- debian package is named python3-swh.icingaplugin
- python module is named swh.icinga-plugins
- archive pushed for the python module is name swh.icinga_plugins

So this defines an explicit extra entry name `python_module` used to start the
debian package build (out of the pypi module artifact holding that name).

This fixes the build [1]

[1] https://jenkins.softwareheritage.org/job/debian/job/packages/job/DICP/job/update-for-release/3

Related to T2654

pip install $(./bin/pip-swh-packages --with-testing) has the side effect to get
some swh modules from PyPI because they are declared in some requirements-test
files. This breaks the installation ordering based on the topological sort of
swh module dependencies graph and thus some modules ended up being installed
in non editable mode.

So ensure all swh modules are installed in editable mode first before
installing test dependencies.

Also this requires a recent version of pip as some modules still end up
being intalled in non editable mode without upgrading it.

Run all test suites and save their output to dedicated log files.

Add Jenkins artifacts for log files of failed tests suites.

Silent verbose maven output.

Packages are currently accumulating old files that have been moved away.

Now that fast hypothesis profile is set by default for swh-storage, we can
remove code explicitely setting it in swh-environment build script.

Add job to run tests for each swh module in their development version
(aka swh dependencies are not retrieved through pip) in order to quickly
detect some breaking changes across modules.

Do not keep tests in memory to avoid possible Chromium renderer crashes and
reduce overall cypress tests execution time.

Keeping tests in memory is only useful when using the cypress GUI.

 - Remove artifacts for most jobs after 20 runs
 - Remove old jobs after 7 days for maintenance jobs

This replaces the mess that forces us to split keyrings into a bunch of separate
files, and should avoid import issues in sbuild as well.

[1] Shows the concatenated chunks are wrong, this fixes it

[1] https://jenkins.softwareheritage.org/view/Debian%20packages/job/debian/job/packages/job/DSTO/job/gbp-buildpackage/168/execution/node/3/ws/keys/cassandra.asc/*view*/

This allows to clarify intents.

The cassandra key file is splitted into 4 chunks of less than 65k as otherwise,
jenkins jobs complain about too big strings.

Because build fails otherwise... [1]

```
17:40:10  org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
17:40:10  WorkflowScript: 237: String too long. The given string is 188459 Unicode code units long, but only a maximum of 65535 is allowed.
```

¯\_(ツ)_/¯

[1]
https://jenkins.softwareheritage.org/view/Debian%20packages/job/debian/job/packages/job/DSTO/job/gbp-buildpackage/165/console

Some signatures contain potential problematic characters.

[1] https://jenkins.softwareheritage.org/view/Debian%20packages/job/debian/job/packages/job/DSTO/job/gbp-buildpackage/164/console