Add backward compatibility in switchsoftwaretype recipe for old default software_type (RootSoftwareInstance)

See merge request nexedi/slapos!1642

See merge request nexedi/slapos!1642

See merge request nexedi/slapos!1640

This test checks that running `slapos node software` command on theia
shell starts installing software, but this command might get an error
like:

    process started, but another slapos process is aleady running with pid 2656158, exiting

this happened for example with https://erp5js.nexedi.net/#/test_result_module/20240911-ED8B4BF9/60

zeo uses temporary files during commit, we want to keep these temporary
files in its partition.
The reason which motivated this change was to prevent problems when
system /tmp is full. It's also consistent to how we configure other
services.

This test uses XMLRPC to control ERP5

this logic was simple enough to be inlined and this makes it easier to
make changes

- Each class now correspond to an instance with different configuration,
and possibly several test methods.
- Upgraded to more recent pypdf version.
- The code has been reviewed to reduce complexity and repetition.
- Adds documentation to all public functions, in Google style.
- Some other cosmetic changes have been made for
consistency (consistent parentheses indentation, consistent string
literal quotes), courtesy of ruff.

See merge request nexedi/slapos!1628

The `enable-scripting` parameter allows to specify a LibreOffice script
to be applied before saving the document, as per
nexedi/cloudooo@a09d87af
If false (the default), an exception will be raised instead.

This commit also adds two SlapOS integration tests classes to test the
functionality:
- TestScripting requests an instance with scripting enabled, and tests
the scripting functionality.
- TestScriptingDisabled tests that scripting fails if it is not enabled
explicitly.

See merge request nexedi/slapos!1628

See merge request nexedi/slapos!1635

See merge request nexedi/slapos!1632

The option "ooo_enable_scripting" can now be set up in the
generic.cloudooo recipe.
This option allows the Cloudooo server to execute user scripts to edit
the documents before they are saved
(see cloudooo@a09d87af3f8bf222cd7d37d814b94ed7a907e2b4).

See merge request nexedi/slapos!1628

Fix clone favicon being the same as the main instance favicon - this
is an uncaught regression. Add a test for it. Also give each clone a
different favicon, in case there are several clones.

See merge request nexedi/slapos!1637

When using older GCC versions (e.g. 8.3.0), Inkscape fails with an error
similar to:

```C++
/srv/slapgrid/slappart15/srv/runner/instance/slappart7/tmp/shared/inkscape/31c6ae5c72c5325d479cca38e62b82bb/.build/inkscape-1.3.2_2023-11-25_091e20ef0f/src/ui/tools/booleans-subitems.cpp: In lambda function:
/srv/slapgrid/slappart15/srv/runner/instance/slappart7/tmp/shared/inkscape/31c6ae5c72c5325d479cca38e62b82bb/.build/inkscape-1.3.2_2023-11-25_091e20ef0f/src/ui/tools/booleans-subitems.cpp:213:61: error: cannot deduce template arguments for ‘uniform_real_distribution’ from ()
     auto ranf = [&] { return std::uniform_real_distribution()(gen); };
```

This may be an instance of this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81486

In any case, setting a minimum version of 10.5 for GCC when building
Inkscape, as done in this commit, seems to fix this.

See merge request nexedi/slapos!1634

This is based on example from https://json-schema.org/understanding-json-schema/reference/object#unevaluatedproperties
this approach allows extending a schema from another software type with
some extra properties while rejecting other properties on instances,
like it's done with additionalProperties: false.

See merge request nexedi/slapos!1633

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

this binary is no longer used

because we are not using anymore and no new release was made to fix
CVE-2024-38428

wget is only used for a peertube self-upgrade script that we do not use

also cleanup to not explitly list parts, having the parts automatically
installed when they are referenced is less maintenance.

wget was used for varnish, which we removed in 24a91de4 (Get rid of
unused/unsupported software type., 2013-07-10). It was still installed
because of this remaining unused reference.

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}

```