1) stack/erp5/zope-versions.cfg
2) stack/slapos.cfg
3) component/ZODB/buildout.cfg.

and remove stack/erp5/ztk-versions.cfg as we need only small part of it.

stack/slapos.cfg should be listed in the begining of software release extends list.

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

We only support wsgi now.

TODO: revert nexedi/slapos.package@63da524b

Only wsgi is supported with Zope 4

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

- MariaDB 10.3.38 & 10.4.28
- mroonga 13.00
- groonga 13.0.0
- groonga-normalizer-mysql 1.2.1

We stopped using it because of 2 data integrity issues:
- https://jira.percona.com/browse/PS-5569 ("FT index corrupt")
- https://jira.percona.com/browse/PS-4291 ("DELETE sometimes do nothing")

TokuDB is also already disabled because transparent huge pages are
enabled by default.

There are more log files with neo

To run the benchmark locally:

 - Install software/slapos-sr-testing and create an instance
 - Source the shell script published by the instance to setup
   environment variables
 - execute `python_for_test -m unittest -v  test.benchmarks`

This promise was generally used to check the connection quality to the
backend with ICMP, by using ping. This is currently obsoleted by health-check
and other parameters in that group.

The parameter to setup the promise is provided by shared instance requester,
that person has no access to those results, as shared instances can't be
monitored directly, all results are only available to the cluster operator in
contrast to health-check, which results are logged to backend_log, to which
shared instance requester has access.

See merge request !1353