Currently librsync 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 librsync to always use the lib directory.

See merge request nexedi/slapos!1629

See merge request nexedi/slapos!1602

wendelin.core 2.0.alpha3.post22 supports being installed by newest
version of pip/setuptools

See nexedi/slapos!1602 (comment 212191)

The rapid-cdn software.cfg manually downloads/copies a setup.py and
a software.py into a folder and then installs it as a develop egg.

Installing a develop-egg creates a .egg-info or a .dist-info into
the source folder.

In rapid-cdn/software.cfg an update-command resulted in the folder
being deleted and recreated on every update for no gain. This also
deleted the .egg-info or .dist-info, breaking the develop egg
installation.

With the zc.buildout 3.0.1+slapos003 release, zc.recipe.egg:develop
is now able to detect such cases and trigger the reinstallation of
the .egg-info or .dist-info. Still, this update-command remains the
cause of useless computations.

Test that slapos-testing compiles and instantiates for each Python
version (software.cfg, software-py2.cfg, software-py3next.cfg).

Donwgrade scipy to be compatible with the version of numpy pinned
in software/monitor - itself downgraded to be compatible with the
version of statsmodels currently pinned to 0.11.1. Upgrading this
will first require adjusting the code in slapos.toolbox that uses
statsmodels, as the next version has breaking changes in the API.

Version up scipy=1.12.0 because scipy 1.8.1 is not compatible with
Python 3.11.

This is a generalisation of macro.pythonpath.eggs which allows paths
from eggs to be placed into any environment variable, and provides a
way to specify subpaths for each egg from the egg location.

Like macro.pythonpath.eggs, the environment variable is placed in an
environment section at install time after the eggs are installed and
before the environment section is read by the section which uses it.

```
[environment-section]
PATH = some/path

[modify-environment]
<= macro.variable.eggs
variable = ANY_VARIABLE
eggs =
  blue_egg
  yellow_egg
  red_egg
subpaths =
  blue_egg subpath/specific/to/blue
  yellow_egg subpath/specific/to/yellow

[section-that-uses-environment]
recipe = zc.recipe.egg:custom
environment = environment-section
depends =
  ${modify-environment:recipe}

```

In case of unavailable backend 502 and 503 are the possible codes, so relax
the assertion.

See merge request nexedi/slapos!1623

Move the versions of matplotlib, matplotlib-inline and cycler pinned in
component/matplotlib/buildout.cfg to slapos.cfg.
The cycler version for Python 3.7 will be upgraded to 0.11.0 as it is
compatible.

One reason motivating this change is that the version of `cycler` in
stack/slapos.cfg is overriding the version specified in
component/matplotlib/buildout.cfg for the erp5-zope2 software release.
This is a problem because the former does not take into account the
Python version, while the later does.
Thus, attempting to compile erp5-zope2 would give the following error:

```
Getting distribution for 'cycler==0.11.0'.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
ERROR: Package 'cycler' requires a different Python: 2.7.18 not in '>=3.6'
While:
  Installing matplotlib.
  Base installation request: 'cycler', 'python-dateutil', 'numpy'
  Getting distribution for 'cycler==0.11.0'.
```

This adds the right version of `cycler` for Python 2 in `slapos.cfg`, so
that it does not fail.

also use archive.apache.org where the link will not disappear even after the release of newer versions.

also use archive.apache.org where the link will not disappear even after the release of newer versions.

  You cannot expand properties with  since it expects
  to be an object or boolean.

  Revert to use allOf back, however set additionalProperties true,
  so the schemas are mutually partially valid.

  Other solutions might too verbose or too restrictive to the use
  case (or simply invalid).

  Include missing #, update wrong url, missing  definition...

  Don't failover to Draft7 if schema is badly defined or undefined.

  Enforce proper definition and raise nicely if the value is bad or
  unsupported.

  Extra: Fixup the list to follow up json schema specification

After the change in https://lab.nexedi.com/nexedi/slapos.core/-/blob/2b80692d62b3dbd9e67d70d6143f180fc2f155fc/slapos/util.py#L449-453, there is now a KeyError message if the serialisation is not found. The theia test was actively checking there is no "Error" in the output log hence it was now failing.

Allow just this specific error.

  allOf implies that all (both) schemas should be valid, but
    additionalProperties false wont allow it, since it become multually
    invalid. (You can validate only one or None)

  Just use $ref to expand the list, it end up with the expected outcome
   reducing complexity.

  Note: kvm wasn't using additionalProperties false but it was changed
   because it makes it future proof, in case we set it (we should set).

Logs for the whole process shall be formatted in the same way, so define it
once in global section.

Long request lines result with truncated logs, which leads to impossibility to
debug cluster.

Maximize the log lines emitted by haproxy, and follow up this withing
accompanying rsyslogd.

Allow very long, but still much smaller, URI logging.