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 !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 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

Let's pick up all fixes and improvements accumulated upstream to be used together with Zope4/Python2.

/reviewed-by @jerome, @levin.zimmermann
/reviewed-on nexedi/slapos!1332

See merge request nexedi/slapos!1331