Re-add

```
[openssl]
<= openssl-1.1
```

in components, and re-remove it from component/python-2.7/buildout.cfg.

This commit is kept separate on purpose until nexedi/master is stable.

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.

In preparation to move all the

```
[openssl]
<= openssl-1.1
```

from individual Python2 SRs to a common stack/slapos-py2.cfg
introduced next.

This commit is kept separate on purpose until nexedi/master is stable.

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.

Follow https://tech-academy.amarisoft.com/NR_TDD_Pattern.html#Test_4

With newer setuptools that is coming via nexedi/slapos!1550 (44.1.1 -> 67.8.0)
we will need a fix from setuptools-dso 2.10 to handle `python setup develop` well:

Previously with setutools-dso 2.9 and setuptools 67.8.0 built shared libraries were not
copied back into the working tree upon develop install which made anything
using pygolang to fail as e.g.

    $ ../bin/gpython
    Traceback (most recent call last):
      File ".../../bin/gpython", line 20, in <module>
        sys.exit(gpython.main())
      File ".../pygolang/gpython/__init__.py", line 456, in main
        pymain(argv, init)
      File ".../pygolang/gpython/__init__.py", line 223, in pymain
        init()
      File ".../pygolang/gpython/__init__.py", line 447, in init
        import golang
      File ".../pygolang/golang/__init__.py", line 41, in <module>
        from golang._gopath import gimport  # make gimport available from golang
      File ".../pygolang/golang/_gopath.py", line 65, in <module>
        from golang import sync
      File ".../pygolang/golang/sync.py", line 36, in <module>
        from golang._sync import \
    ImportError: liblibgolang.so.0.1: cannot open shared object file: No such file or directory

See https://github.com/mdavidsaver/setuptools_dso/pull/29#issuecomment-1745790761
and https://github.com/mdavidsaver/setuptools_dso/commit/2fdf75f2 for details.

P.S. NOTE that changing version of a setup-egg required egg currently does
_not_ force a rebuild. In other words pushing this change into testnodes won't
make pygolang t o be rebuilt at all. I think this is simply a bug in
slapos.buildout to fix.

/reported-by @xavier_thompson
/cc @jerome, @tomo, @kazuhiko
/reviewed-on nexedi/slapos!1585

See merge request nexedi/slapos!1578

This is done as an alternative to the patch in !1580, as the last
version is already patched.

See merge request nexedi/slapos!1582

without this change, configure would use openssl lib for MD5, sha256sum, ...
if openssl development files are present on the system.

Previously, zstd support was only compiled if zstlib was installed in
the system.

This especially brings support for systems where 'model name' is not
present in /proc/cpuinfo

the previous version was failing like this if lib64 doesn't exist:

libcap: Command 'set -e;cd /opt/slapgrid/shared/libcap/4d09237abd7cb34117fccc1d3c3bc862
[ -d lib64 ] && ln -s lib64 lib' returned non-zero exit status 1

option --enable-readline doesn't exist anymore (has it ever?)

We need to add option --disable-initial-exec-tls because we hit the bug
shown in https://github.com/jemalloc/jemalloc/issues/937 with mariadb:

2024-05-19 16:01:21 0 [ERROR] mysqld: Can't open shared library '/srv/slapgrid/slappart71/srv/runner/shared/mroonga-mariadb/be92b7e01c15aff71b79dd45214ed316/lib/plugin/ha_mroonga.so' (errno: 22, /srv/slapgrid/slappart71/srv/runner/shared/jemalloc/049efd1ae7af39cea251f2a2fe3a89ca/lib/libjemalloc.so.2: cannot allocate memor)

INFO     pcre_jit_compile.c:65:2: error: #error Unsupported architecture
INFO        65 | #error Unsupported architecture
INFO           |  ^~~~~

See https://github.com/luvit/pcre/blob/5c78f7d5d7f41bdd4be4867ef3a1030af3e973e3/pcre_jit_compile.c#L65

only for python3

We now need to install lxml-clean-html separately, see the following
message:

  File "/srv/slapgrid/slappart71/srv/runner/software/e16145ec9280f63bd6c28ca2758d03f0/develop-eggs/lxml-5.2.1-py3.9-linux-x86_64.egg/lxml/html/clean.py", line 18, in <module>
    raise ImportError(
ImportError: lxml.html.clean module is now a separate project lxml_html_clean.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090

We need to patch ffmpeg to be able to compile with this version of
binutils.

Currently libsnappy is being compiled in the folder lib64 in some
OSes (e.g. SUSE SLE 15.6).
This is a problem because some dependents look for the library in the
lib subdirectory.
This change forces snappy to always use the lib directory.

See merge request nexedi/slapos!1581

This is a follow-up of 7a1ba8df.