See merge request nexedi/slapos!1559

This reverts commit 3ff25131d56c7f66066b70191ac828a666600e92.

by default on riscv architecture, the libffi.so will be placed in
lib/lp64d but everywhere else in buildout (and especially for the
compilation of python3) we expect the lib to be in lib/ directory.

SlapOS.Eggs.UnitTest-Master.Python2 also installs old scipy so it needs
old gcc

See merge request nexedi/slapos!1557

Also remove old unused gcc version

unfortunately, there is no official release anymore so use a commit from
master.

This reverts commit 3d63cd39.

This reverts commit 1bd75eee.

  The backend haproxy must not handle the arbitrary variable Remote-User from headers.

It isn't implemented authentication on this backend, so this setting is irrelevant by default.

The proper way to handle authentication is use a trustfull frontend that will set this variable after properly authenticate the certificate and extract the user.

  For now the only exception is slapos_configurator only

While running tests using all.bash, `$HOME/.cache/go-build/` is
populated with data referencing the build folder. This is problematic
when using shared parts and installing a not pinned software release
multiple times, like it is the case on test node.

A scenario like this can happen:

 - a first succesful build install in `<shared>/golang1.21/<HASH1>`
 - golang1.21 section is changed in a the software release
 - golang1.21 is installed in `<shared>/golang1.21/<HASH2>`, running
   test fails because the cache `<software_folder>/.cache/go-build/` in
   references paths from `<shared>/golang1.21/<HASH1>/.build/go/src`,
   that was used when building the first build and have been removed
   while installing.

This is visible with errors like this:

    2024-03-21 20:52:37,214 INFO     slapgrid_sr: 2024-03-21 20:52:37 slapos[23849] INFO vet: can't parse raw cgo file: open ../../../../a984f246a1b2789081965ab5c05674a8/.build/go/src/net/cgo_linux.go: no such file or directory

See merge request nexedi/slapos!1551

See merge request nexedi/slapos!1548

This reverts commit 5814aadb.

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