Use older numpy=1.22.0 to remain compatible with statsmodel=0.11.1.
Use older setuptools=44.1.1 to be able to install numpy=1.22.0.

dnspython=2.1.0 requires poetry as build backend.

Older Theia versions no longer compile inside test nodes since we
prevent using the system python.

Remove obsolete upgrade tests since we now upgrade from a Theia
version after merge request !1399.

Export (theia0) and export (theia1, ...) instances published
connection parameters twice, once without and once with the
resiliency connection parameters. Keep only that last one.

Use official SOAPpy=0.12.22 compatible with pip.
Downgrade zope.authentication=4.5.0 because 5.0 requires Python>=3.7.

Reverts 15871bbf

This SR is kept separate because it is not part of current tests.

When using slapos.reboostrap to re-launch buildout with the version
of Python that was just installed, zc.buildout and its dependencies
are reinstalled for the new Python with the same egg versions. Thus
SRs which install Python 2 need to use Python-2-compatible versions
of setuptools, pip and wheel all along.

For this stack/slapos-py2.cfg is introduced.

Except for python2: keep beautifulsoup4=4.8.2.

beautifulsoup4=4.12.2 requires flit as build backend.

backcall=0.2.0 requires flit-core as build backend

entrypoints=0.3 rquires flit as build backend

pkgconfig=1.5.1 requires poetry as build backend.

Earlier version 1.22.0 does not support recent setuptools.

Latest version 1.26.2 has more complex build requirements,
left for later.

Now that buildout uses pip to correctly follow pyproject.toml,
cattrs=22.2.0 requires poetry as the build backend.

For now it's easier to install as wheel than to install poetry and
then use it as setup-egg for cattrs. This must be done eventually.

zc.buildout=2.7.1+slapos020 is SlapOS-patched buildout2 with support
for bootstrapping buildout3, required to be able to install buildout3.

Downgrade related eggs to pre-buildout3 versions as well.

Version up zc.buildout, pip and zc.recipe.egg.

Version up slapos.rebootstrap to adapt to buildout3.

See merge request nexedi/slapos!1551

See merge request nexedi/slapos!1548

This reverts commit 5814aadb7234c6772e855c5549afbb09feeb1f5e.

Grrr Jinja2 does not want me to write:

{%-   if any(node.get(x, 1) for x in ('admin', 'master', 'storage-count')) %}

See https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED

Setting a value will set the environment variable for all zope processes
and for the test runner.

Default behavior is:
  - for zope: do not set the variable, so default python behavior will
  be used ( equivalent to setting `0` on python2 and `random` on python3)
  - for test runner: generate a random value for each execution and
  print it, to make it easy to re-run a failing test with the same seed.

This means that ERP5 tests will likely reveal problems where code
depends on python2 behavior of deterministic hashing. To keep previous
behavior (and hide these problems), it's possible to set
python-hash-seed to 0 in test suite parameters.

See merge request nexedi/slapos!1553

See:
nexedi/rubygemsrecipe!10
nexedi/slapos.buildout!29

The CertificateAuthority tool in ERP5 uses UTF8 encoding for certificates,
but by default OpenSSL does not. This cause an error when using non-ascii
characters:

```
The localityName field is different between CA certificate and the request
```

To solve the problem, the Certificate Authority recipe should use the same
encoding as ERP5, which requires adding `-utf8` option when invoking
OpenSSL.

For instance, creating a certificate with `localityName` Москва
will give the following with the default OpenSSL encoding:
`\C3\90\C2\9C\C3\90\C2\BE\C3\91\C2\81\C3\90\C2\BA\C3\90\C2\B2\C3\90\C2\B0`.

UTF8-encoding this same string gives `\D0\9C\D0\BE\D1\81\D0\BA\D0\B2\D0\B0`,
which is what ERP5 expects.

See merge request nexedi/slapos!1552