Notifying erp5 when a read occurs isn't as straightforward as sending a
request to erp5 when a data change occurs.

I think the reason for this is that OPC UA has the concept of subscriptions [1].
But as far as I understand it this concept only applies to important events
as data changes or OPCUA Events, but not to simple "read" or "browse"
requests. So to catch those requests and forward them to ERP5 we actually
need to adjust asyncua.

In this patch I picked a dirty-adhoc-monkey-patching approach, a cleaner
version may include defining a new custom ERP5Server, which inherits
from asyncua base Server class.

Because (AFAIK) it's not possible to track the read requests with the
subscription method, we may want to unify our forwarding system by dropping
the subscription approach and move everything to a patched InternalSession.

[1] https://documentation.unified-automation.com/uasdkhp/1.4.1/html/_l2_ua_subscription.html

This fixes the following error in zope:

bash-5.1$ slapos node tail slappart6:zope-0-7b91211283be978a19e1bb10e54dc284-on-watch
e76946300062f86fcc7/eggs/haufe.requestmonitoring-0.6.0-py3.8.egg/haufe/requestmonitoring/monitor.py", line 28, in <module>
    from zope.app.appsetup.interfaces import IProcessStartingEvent
  File "/srv/slapgrid/slappart45/srv/runner/software/6afc47a0c1078e76946300062f86fcc7/eggs/zope.app.appsetup-3.16.0-py3.8.egg/zope/app/appsetup/__init__.py", line 20, in <module>
    from zope.app.appsetup.appsetup import config, database
  File "/srv/slapgrid/slappart45/srv/runner/software/6afc47a0c1078e76946300062f86fcc7/eggs/zope.app.appsetup-3.16.0-py3.8.egg/zope/app/appsetup/appsetup.py", line 29, in <module>
    class SystemConfigurationParticipation(object):
  File "/srv/slapgrid/slappart45/srv/runner/software/6afc47a0c1078e76946300062f86fcc7/eggs/zope.app.appsetup-3.16.0-py3.8.egg/zope/app/appsetup/appsetup.py", line 30, in SystemConfigurationParticipation
    zope.interface.implements(IParticipation)
  File "/srv/slapgrid/slappart45/srv/runner/software/6afc47a0c1078e76946300062f86fcc7/eggs/zope.interface-5.4.0-py3.8-linux-x86_64.egg/zope/interface/declarations.py", line 778, in implements
    raise TypeError(_ADVICE_ERROR % 'implementer')
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/srv/slapgrid/slappart45/srv/runner/software/6afc47a0c1078e76946300062f86fcc7/eggs/haufe.requestmonitoring-0.6.0-py3.8.egg/haufe/requestmonitoring/monitor.zcml", line 5.2-5.49
    File "/srv/slapgrid/slappart45/srv/runner/instance/slappart6/srv/erp5shared/etc/site.zcml", line 26.2-26.66
    TypeError: Class advice impossible in Python3.  Use the @implementer class decorator instead.

zope.app.appsetup 4.2.0 is the first version which supports py3.8:

  https://pypi.org/project/zope.app.appsetup/4.2.0/#section-1

We currently use python 3.8:

[1] https://lab.nexedi.com/nexedi/slapos/blob/d2404ed9/stack/erp5/buildout-py3.cfg#L36
[2] https://lab.nexedi.com/nexedi/slapos/blob/7d78a928c09b63508c69f84aa499a9870b3ae37e/component/python3/buildout.cfg#L21

caddy-frontend-N is bad name, it's just frontend-node-N.

This option was useful only during the time, when there were experiments
running on caddy-frontend clusters during switch to HTTP/2.

Currently HTTP/2 is a standard, and there is no reason to disable it globally.

Attention, this change will require manual intervention on the upgraded
cluster with:

sed -i 's/^recipe = caddyprofiledeps/recipe = software/g' .installed*

On each partition.

NAME_BASE is set on top of the file with informative warning, so that
developers are aware of consequences.

instance-slave-caddy-simplified-input-schema.json has been removed, as it is
not useful.

Some profiles were templates and vice versa, which was very
misleading.

The most complex case - no automatic https redirection and usage
of url and https-url is used to check implementation of type:redirect now.