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.

It is also used to move all

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

from individual Python2 SRs to a common place.

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.

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

Version up slapos.rebootstrap to adapt to buildout3.

Some phones with Android 12+ disconnects from
5G networks which don't support IMS. Therefore
we add minimal IMS support in this commit (even
though we don't actually need it's features).

Only Amarisoft >= 2024-05-02 support launching
lteims without root privilege, so if Amarisoft
version is older IMS is disabled and we inform
the user so in the connection parameters.

For this to work, SIM cards config needs to be
modified, impu and impi must be for instance:
impu: 001010000001312,
impi: 001010000001312@ims.mnc001.mcc001.3gppnetwork.org

 - pycrypto does not seem used (because it does not work on py3 with buildout3)
 - cns.recipe.symlink and PyRSS2Gen versions are defined in stack/slapos.cfg

See merge request !1587

Revert eb1b1a41 to avoid the use of
`fPIC` flag as it is a "contagious" build option.

To not face the build error "relocation R_X86_64_32 against
.rodata.str1.8 can not be used when making a shared object; recompile
with -fPIC" while building a shared library without fPIC flag, `gcc` is
compiled with `-enable-default-pie` flag (which is a compilation option
used for `gcc` binaries provided by Debian by example, see `gcc -v`).

Since slapos package provides gettext, it is not necessary to build
gettext here. Also slapos package's gettext commands such as msgfmt
may not work with libraries built by a software release, thus remove
LD_LIBRARY_PATH.

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