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 logic was simple enough to be inlined and this makes it easier to
make changes

This brings updates of many dependencies on python3, while mostly
keeping the same versions for python2.

This enables a new `erp5-py3` test in software/slapos-sr-testing, which
should pass already, but with NEO and WCFS being marked as expected
failure or skipped for now.

This also brings pylint support on python3, which we will be able to
reuse in software/slapos-testing.
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>
Co-authored-by: Arnaud Fontaine <arnaud.fontaine@nexedi.com>
Co-authored-by: Bryton Lacquement <bryton.lacquement@nexedi.com>

This reverts commit 6c399134.

Zope no longer serve XML-RPC in ERP5, unless it is explicitly enabled
using this.

* use the default RSA key length, instead of hardcoding 1024 (too weak) or 2048 (same as the current default).
* use SHA256 in certificates.

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.

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.

This parameter no longer exists, this was not removed correctly

"repozo --verify" is not working as this code expects it to: it simply
prints errors in stdout, and doesn't return an error code in case of
error. Thus, running it had absolutely no effect, except wasting IO
and CPU time.

This commit introduces the use of "repozo --recover --with-verify",
which runs the verify and the recover in a same step, and has the
advantage to raise (it doesn't exit with 0) in case of error. Also, as
it does the verification and the recovery at the same time, it uses
half the IO for the read. On a production server using SSDs, with a
ZODB of 1Tb, runner-import-restore now takes 14h instead of 26h, iow a
performance increase of 46%.

The strategy for compatibility is that:
 - haproxy still listen on the same port as before, without rewrite rule.
   This is called "legacy" port.
 - for each frontend from request parameters, we introduce an haproxy
   frontend with a rewrite for the corresponding `internal-path`
   parameter.
 - the shared frontend instance is updated to use this new frontend
   entry from haproxy. This will cause a small downtime until the shared
   frontend is updated to the new URL on ERP5, but since this feature
   was not used, it's OK.

Technical details are that we:
 - split haproxy config to have frontends and backends.
 - introduce one frontend in haproxy for each frontend from request
   parameters.
 - routing-rule-list argument is still honored the same way, globally
   and after path from frontend.
 - change the shared frontend requests to use "" type, no longer "zope"
   type.
 - we don't do automatic detection of /VirtualHostRoot in URL but always
   add it, because it could be used to trick zope into thinking it
   serves requests for an arbitrary host and do open redirects
 - before using the request's host header in virtualhost path, we check
   that it does not contain /, to prevent injection of virutalhost path
   elements through the host header.
 - we don't use the "path" parameter from shared frontend, because we
   want the frontend to be simple, so we don't want it to rewrite the
   request path (which is also the reason why we deprecated "zope" type)
 - the tests have changed a lot, because they were using what's now the
   "legacy" URL types, so we updated it to use the new URL types with
   all the /VirtualHostRoot/../ in path and also because they use IPv6
   URL, no longer IPv4

and save the already allocated ports in a state file, so that requesting
new families does not change already allocated ports.

This reverts commit 620c9332 (stack/erp5: stop using caucase managed
certificate for balancer, 2020-11-10) with an updated design. We add a
caucase service for balancer in the balancer partition. The caucase
service from the root partition (that was not used) is removed.

The underlying idea is that the default configuration should use multiple
caucases with limited scope, here we have one caucase to manage the
certificate used by haproxy server in the balancer partition, so we put
one caucase to manage this certificate and the caucase is configured to
auto-accept one certificate only. The plan is that when we will add a
certificate for mariadb server, we'll add another caucase inside this
mariadb server.

For more advanced usage and also to support the cases where a new
certificate needs to be re-emitted for some reason, users can request
with an existing caucase URL. In that case, they will have to accept
the certificate requests.

Notable changes:

balancer/ssl/caucase-url is no longer documented in parameters, this is
an internal parameter, users can pass one global caucase service to
manage all partition

CAUCASE environment variable is no longer set when running zope. There
was no identified use case and with this new approach of multiple
caucases, the term "caucase" alone became ambiguous.

This is not documented in schema and has no effect in erp5 (but this is
still used for slapos-master)

This change the format or the (mostly) unused frontend parameter to
support requesting more than one frontend and also enable the request of
a frontend by default, so that requesting a frontend separately is no
longer needed.

The `frontend` parameter now also supports requesting frontends for
specific paths on the ERP5 backend, the example below requests a
frontend serving directly a web site, with the necessary rewrite rules:

```js
{
  "frontend": {
    "default": {
      "internal-path": "/erp5/web_site_module/renderjs_runner/"
    }
  }
}
```

The example below requests a default frontend to the erp5 root, to
access the ZMI or erp5_xhtml_style interface and two web sites:

```js
{
  "frontend": {
    "default": {},
    "erp5js": {
      "internal-path": "/erp5/web_site_module/renderjs_runner/"
    },
    "crm": {
      "internal-path": "/erp5/web_site_module/erp5_officejs_support_request_ui/"
    }
  }
}
```

The example below has an explicit definition of the zope families using
`zope-partition-dict` parameter, because there is more than one zope
family, no frontend is requested by default:

```js
{
  "zope-partition-dict": {
    "backoffice": {
      "family": "backoffice"
    },
    "web": {
      "family": "web"
    },
    "activities": {
      "family": "activities"
    }
  }
}
```

Continuing this example, to have frontends for backoffice and web
families, the frontend request can specify the families, like it is
demonstrated in the example below. In this example, we don't specify an
entry for "activities" family, so no frontend will be requested for
this family.

```js
{
  "frontend": {
    "backoffice": {
      "zope-family": "backoffice"
    },
    "web": {
      "zope-family": "web",
      "internal-path": "/erp5/web_site_module/web_site/"
    }
  }
  "zope-partition-dict": {
    "backoffice": {
      "family": "backoffice"
    },
    "web": {
      "family": "web"
    },
    "activities": {
      "family": "activities"
    }
  }
}
```

In Wendelin we mostly always want to run our zopes with the soft limit
set to the hard limit.

/reviewed-by @jerome, @jm, @rafael, @vpelletier
/reviewed-on nexedi/slapos!1465

---

This patch was already added in nexedi/slapos!1451, but
removed (by force push), due to issues discussed in nexedi/slapos!1451 (comment 193296).

nexedi/erp5@39369169 added the functionality to ERP5 to
set its soft limit of allowed open file descriptors to the system wide hard limit.
This parameter is useful for Wendelin based instances where the 1024
limit is easily reached.

With this patch, this parameter can also be set via SlapOS, which
simplifies usage of the Wendelin SR.

/reviewed-by @jerome, @jm, @rafael, @vpelletier
/reviewed-on nexedi/slapos!1465

---

This patch was already added in nexedi/slapos!1451, but
removed (by force push), due to issues discussed in nexedi/slapos!1451 (comment 193296).

Empty values are considered not provided, so provide a template which
produces a file with a lone comment.

stdout/stderr is sent to supervisor and we don't want buffering the
output in that case, because it introduces a delay in the output and
break the usage of `slapos node supervisorctl fg` to re-attach the
process and use pdb

We configure haproxy with "verify optional", which makes haproxy request
a client certificate, but accept the case where client does not present
a certificate, but as described in [1], if client present a certificate
and this certificate can not be verified, handshake is aborted. This is
not what we want, we want to treat the case of a non verified
certificate same as the case of the absence of certificate.

This configures haproxy accordingly, using "crt-ignore-err all" to allow
handshake anyway.

Once this was fixed, there was a remaining problem with
client_cert_verified acl, haproxy acl are OR, but this rule was supposed
to be a AND (client present a certificate AND it is verified), this was
rewritten to use inline condition which are AND.

[1]: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-verify

Also adjust test_x_forwarded_for_stripped_when_no_certificate to assert
that there is no X-Forwarded-For header at all when no client
certificate.

  https://archive.fosdem.org/2023/schedule/event/innodb_change_buffer/
  https://jira.mariadb.org/browse/MDEV-27734
  https://mariadb.com/kb/en/innodb-change-buffering/

Promise from a8271791 (stack/erp5: new promise to check software
release URL of zope instances, 2020-12-04) was never executed. Adding
the section seemed to be change timing to make the upgrade test, but
this was not correct to not run the promise.

For more detail see discussion on
nexedi/slapos!1414 (comment 189341)

These md5 changes come from unrelated changes.

Fixes building gcc-8.5.0 on libc6 version 2.36 (at least).
Fixes this error:
  configure: error: in `.../parts/gcc-8.5/.build/gcc-8.5.0':
  configure: error: C compiler cannot create executables
  See `config.log' for more details.
relevant config.log extract:
  configure:4326: gcc   -Wl,-rpath=.../parts/gmp/lib -Wl,-rpath=.../parts/isl/lib -Wl,-rpath=.../parts/mpc/lib -Wl,-rpath=.../parts/mpfr/lib conftest.c  >&5
  .../parts/binutils/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'

log files used by neo storage are not text files, they are sqlite
databases, so we can not use copytruncate because it leaves a broken
database. For neo, we have to go back to sending a SIGUSR1 signal to
tell neo client to reopen log files. This depends on neo registering
a signal handler, which is done in [1]. It depends on ZServer, so this
approach will probably have to be adjusted when running on python3
because the current plan is that we don't have ZServer installed on
python3.

This depends on a recent erp5.git where runwsgi understands --pidfile
argument.

1: https://lab.nexedi.com/nexedi/neoppod/blob/fd87e153/neo/client/app.py#L58

In nexedi/slapos@0cf70a6e we already migrated the NEO URI concatenation to the
recent format used by WCFS. Unfortunately we missed separating the address
(IPv6 + port) of the master nodes from each other. Without adding the
separator ',' between them, WCFS doesn't work with NEO clusters which have
multiple master nodes, because NEO/go can't split the different master node
addresses.

ERP5 now only supports WSGI

This needs a recent enough erp5, with the following commit:
zopewsgi: configure threads count and large_file_threshold with argparse

haufe.requestmonitoring already supports WSGI and Python3 and seems
used and maintainted.

For ZEO4, this was implemented as a monkey patch in ERP5, but this is
now supported in ZEO5, but not enabled by default.

The setting is only avaiable through ZEO's own ZConfig, but not with
ZODB's <zeoclient> so we also adjust the config to import ZEO and use
ZEO's <clientstorage>.

SIGUSR2 for reopening log files was handled by ZServer and waitress does not
handle signals at all, so we could handle this signal but Zope official
documentation recommends using logrotate `copytruncate`:
  https://zope.readthedocs.io/en/4.7/zopebook/MaintainingZope.html#log-rotation
  https://github.com/zopefoundation/Zope/issues/809