to take a look before everything is destroyed automatically

This solves the error occuring installing python2 softwares:

    error: find_namespace: directive is unsupported on Python < 3.3
    An error occurred when trying to install pyrsistent 0.14.5. Look above this message for any errors that were output by easy_install.
    While:
      Updating slapos-cookbook-dependencies.
      Getting distribution for 'pyrsistent==0.14.5'.

See nexedi/slapos!1207 (comment 174788)

We want to detect usage of system python2 or python.

https://mariadb.com/kb/en/general-query-log/

https://mariadb.com/kb/en/compiling-mariadb-for-debugging/

https://mariadb.com/kb/en/enabling-core-dumps/

We can probably make a scalability test from this, this a first step to
reproduce the crash

We want the tests to use the code from the repository, but when we have a
pinned version, buildout will use the code from repository only when the
version from the repository match the version spec from the pin.

The way slapos.recipe.template was pinned to 4.4 caused issues when we made
a change in slapos.recipe.template to make it 4.5, because tests were no
longer using code from slapos.recipe.template repository, but from 4.4 egg
from pypi.

To prevent this kind of issues, unset the slapos.recipe.template = 4.4
version pin and also unset the version for all tested egg, to prevent
similar issues if extended profiles also have version pins.

See merge request nexedi/slapos!876

This reverts commit 2f461da8.

Since Galene is behind our frontend, no need to take care of the HTTPS certificates.

See merge request nexedi/slapos!880

This also pulls in crawshaw.io/sqlite because it is used by lonet.

Due to unknown yet reason ATS and Caddy are loosing connections to haproxy,
which results with increased amount of 5xx (about 0.5% more cases).

No known solution was found yet on haproxy side, but this kind of workaround
stabilises frontend and definitely drops amount of in-frontend 5xx. The
observed situation with this workaround is no more 5xx sourcing in frontend
itself.

See merge request nexedi/slapos!878

See https://galene.org
Use first official version (0.1)
Co-authored-by: Thomas Gambier <thomas.gambier@nexedi.com>

See merge request nexedi/slapos!868

Introduce a new "software release upgrade test", which tests a scenario of keating
an ERP5 instance with an old version of software release and then update it to
current version.

To support this test and because we are using this technique for most of slapos
softwares nowadays, configure zopes to restart automatically when their
configuration change.

See merge request nexedi/slapos!875

Confirms SlapOS ERP5 software release can be updated from
a reference version to current version

When root instance is updated to a new software release URL, it will re-request
all the instances with the new software release URL.
To make sure the new root instance does not appear has ready when it is
re-requested with new software release URL, introduce a promise that will check
that the instances requested by the root instance have the same software
release URL. For now we do this only for Zope instances, because they are
stateless and restart automatically on configuration changes, unlike stateful
instances like mariadb or ZEO that we don't restart automatically (yet ?).

We are using this pattern for most of our services since several
months without any issue, so let's also use it for zopes. This
makes automatic upgrade possible.

Also remove "zope running current products" promise, since we
restart we no longer need to check this.

moves python2 release to component/jupyter-py2 because it is required by ERP5
but not maintained anymore

moves to python 3 :
- test/test.py
- jupyter_notebook_config.py.jinja
- ERP5kernel.py

modifies custom.js to create a workaround for events issue
see (https://github.com/jupyter/notebook/issues/2499)

upgrades slapos.cookbook version to 1.0.171 to use zero_knowledge recipe
with python 3

adds jupyter partition check in software/erp5/test/test_erp5.py