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

Now the ERP5 SR creates an OPC UA server as an additional service which
runs on the default ipv4/ipv6 on port 4840.

This service notifies ERP5 whenever any read or write operation happened
on any OPC UA node. It also notifies ERP5 if any other OPC UA event
happens. It does so by calling the ERP5 script "opcua_test".

This new component creates a bin, which can be used to run an OPC UA
server [1] as a SlapOS service.

[1] https://opcfoundation.org/about/opc-technologies/opc-ua/

We also need various ERP5 side changes for the new OPC UA support
feature. During development we therefore use a specific ERP5 branch.
Once merged, the ERP5 side patches should also be merged and this
patch can be dropped.

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.

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

3.7.3 is an "urgent" new release as announced in
https://www.postfix.org/announcements/postfix-3.7.3.html
the old 3.7.2 version seem to have bee removed from mirrors
(see http://postfix.mirrors.ovh.net/postfix-release/official/ for a
mirror with directory index) and was not in shacache.

using link-binary is enough