When user ran out of inotify watch, starting wrappers using
wait-for-files is not possible:

    AssertionError: Traceback (most recent call last):
      File "/srv/slapgrid/slappart15/tmp/tmpzurwmg4q/wrapper", line 13, in <module>
        sys.exit(slapos.recipe.librecipe.execute.generic_exec(['/bin/echo', 'done'], wait_list=['/srv/slapgrid/slappart15/tmp/tmpzurwmg4q/wait']))
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 100, in generic_exec
        _wait_files_creation(wait_list)
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 30, in _wait_files_creation
        watchdescriptors = {inotify.add_watch(dirname,
      File "/srv/slapgrid/slappart15/srv/project/slapos-clean/slapos/recipe/librecipe/execute.py", line 30, in <dictcomp>
        watchdescriptors = {inotify.add_watch(dirname,
      File "/srv/slapgrid/slappart15/srv/project/venv/lib/python3.9/site-packages/inotify_simple.py", line 110, in add_watch
        return _libc_call(_libc.inotify_add_watch, self.fileno(), fsencode(path), mask)
      File "/srv/slapgrid/slappart15/srv/project/venv/lib/python3.9/site-packages/inotify_simple.py", line 39, in _libc_call
        raise OSError(errno, os.strerror(errno))
    OSError: [Errno 28] No space left on device

This catches inotify errors and fallback to simple polling in that case.

Running logrotate -d on cluster with a lot of slaves results with execution
taking a lot of time (>10s, one some nodes ~20s), which leads to random
promise timeouts.

instance-slave-list.cfg.in is run by instance-frontend.cfg.in, which
implements that exact promise already.

Default software_type requests all required instances for the swarm.

See merge request nexedi/slapos!1264

Add getSpeed and getClimbRate to drone's API

Update FPS value to respect minimum sampling value of open62541 monitored items

Make sure to stop Pub/Sub server before stopping MavSDK thread

Now the default software-type request a list of drone software-type

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

keep old versions for python2

also sort versions and remove comments that make it hard to sort
versions and are not so helpful:
 - we can find the dependents of a package by looking in
  *eggs/*/EGG-INFO/requires.txt
 - nowadays, many python packages no longer have setup.py and wheels
  is becoming standard.

jsonschema egg now needs typingextension egg so we needed to pin it

In order to cleanup, I moved all eggs at once.

This reverts commit b3afa3fe.

This change unexpectedly impacted ERP5 deployment.

See merge request nexedi/slapos!1327