It's just type:websocket without any path and with transparent parameter,
thus resulting with providing X-Real-Ip to the backend.

haproxy supports websocket by default everywhere, so reuse this and make
type=websocket only needed if some specific configuration like
websocket-path-list or websocket-transparent have to be set.

As a result of implementing this feature X-Forwarded-Proto and
X-Forwarded-Port header support is now enabled per slave and not just
globally.

X-Real-Ip is only available for websocket paths, previous implementation
was simply wrong, and this has been fixed and asserted in tests.

Tests have been slightly updated to make it easier to follow the real
websocket logic.

Cipher translation is implented on the node, so that old style and new style
nodes can co-exists in the same cluster, thus making partial upgrade possible.

Caddy was automat(g)ically adding Content-Type header to the backend
response, but Haproxy does not do it, and change of the servers shall
follow generic approach that not additional information is added to the
response by the CDN.

In case if Date header is present do nothing otherwise add one.
Test backend is adapted to have full control over headers sent.

Backward incompatible change happens, as the Date header is generated
before passing the request to the cache, thus resulting with caching it.
Nevertheless this is good change, as previous behavior was simply wrong.

mpm-graceful-shutdown-timeout is dropped, as it's historical leftover and never
really useful in the caddy-frontend CDN usage context - stopping the server is
the most rare situation, and any grace period is solved eventually outside of
the running process (like redirecting traffic elsewhere before stopping).

haproxy since 2.4 requires correctly ending files, thus do it by adding
in-jinja comment which will result with LF in the end.

It's based on phased out caddy-frontend, especially as next step is to drop
Caddy software from the software release.

2.6 implementes url normalization, needed on front facing part, see
https://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-http-request%20normalize-uri

We don't care about exact exception message, but we only want to test
that the client can't connect anymore once banned. Relaxing this
assertion should stabilize previously flaky
'TestBan.test_client_are_banned_after_5_wrong_passwords'.

See nexedi/slapos@97f4a5fb (comment 150049)
and nexedi/slapos!1305 (comment 175255)
for additional context.

The workaround seems to be required for several OlinuXino boards (https://github.com/OLIMEX/OLINUXINO).
See !915

Disable java

Do not update vscode-uri yet, because theia does not support vscode-uri 3 currently, so we have to keep our patch.

See merge request nexedi/slapos!1315

Sometimes this script is slow, add some logging to display progress
also use a Session to pool connections and apply a timeout to fail more
faster in case of network/server problems

This is big, fails on raspberry pi and we don't really use it

See merge request nexedi/slapos!1303

The NEO/go commit neo@8c974485
changed the URL with which a NEO/go client can be loaded from

    // neo://name@master1,master2,...,masterN?options

to

    neo(s)://[credentials@]master1,master2,...,masterN/name?options

We need to apply this change in the NEO URL structure to instance-wcfs.cfg.in
to use WCFS with NEO storage.

Why?
====

The URL in instance-wcfs.cfg.in is finally send to wcfs binary, which
will open a NEO/go client with this URL via the "openClientByURL" function [1].
If the URL formatting instance-wcfs.cfg.in follows the old pattern,
NEO/go is unable to create a NEO/go client and may even raise an
exception [2], because information regarding NEO server is at the wrong
position of the URL.

---

[1] See https://lab.nexedi.com/kirr/neo/blob/87199da2b163c09ed3946b7ab9bb00a5b987d377/go/neo/client.go#L416-534
for openClientByURL.

[2] For instance when using the old pattern of putting the cluster name
in the "user" part, NEO/go will raise "credentials can be specified only
with neos:// scheme", because NEO/go reserves the "user" part for
encryption information,
see https://lab.nexedi.com/kirr/neo/blob/87199da2b163c09ed3946b7ab9bb00a5b987d377/go/neo/client.go#L449

---

/reviewed-by @kirr
/reviewed-on nexedi/slapos!1307

Go1.18 is the next stable go release. There is already Go1.19
(released 2022-08-02), but we incrementally increase versions.
For Go1.18 there are already many bug fix releases (last one
2022-12-06) which gives it a more stable/mature impression.

/reviewed-on nexedi/slapos!1305

Go 1.18 is the incremental improvement for earlier go 1.17 release.
Is "is a significant release, including changes to the language,
implementation of the toolchain, runtime, and libraries". Please find
all details in the official release note:

    https://go.dev/doc/go1.18

It was released on 2022-03-15. Due to the go promise of compatibility
most software should still compile without any problems.

/reviewed-on nexedi/slapos!1305

2.x series do not have python3 support

keep 2.9.3 in ERP5 for now, because on master branch we are still
expecting version 2 (zope4py2 branch on the other hand needs version 3)

we have component/kerberos/

Include hash into revision to ensure reproducibility.

See nexedi/slapos!1309 (comment 175109).

New WC2 alpha release provides us with various small fixes:

    nexedi/wendelin.core@5e5ad598...7ce0978d

It also prepares upgrading SlapOS go default version to v1.18
(WC2 alpha2 doesn't work with go1.18).

Tests passed: https://erp5js.nexedi.net/#/test_result_module/20221221-5FEF9030

/reviewed-on nexedi/slapos!1309

 Going from 1.17.6 to 1.17.13 gives us security and bug fixes.
 See at official changelog for details:
    https://go.dev/doc/devel/release#go1.17.minor

Passed tests: https://erp5js.nexedi.net/#/test_result_module/20221219-8E2857F

/reviewed at nexedi/slapos!1304
/reviewed-by @kirr

This is a fixup of 431eed50

The version of pandas was overwritten in
02fad6a8 but didn't work with python2.

Then the version was downgraded to 0.24.2 in
15569ea9 but ERP5 doesn't work with this
pandas version:
Traceback (most recent call last):
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/bin/runTestSuite", line 325, in <module>
    import Products.ERP5Type.tests.runTestSuite
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/__init__.py", line 92, in <module>
    from . import ZopePatch
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/ZopePatch.py", line 30, in <module>
    from Products.ERP5Type.patches import Restricted
  File "/srv/slapgrid/slappart3/t/dgg/soft/63c49071f5be63057dd48d7a85c10226/parts/erp5/product/ERP5Type/patches/Restricted.py", line 491, in <module>
    allow_type(pd.indexes.range.RangeIndex)
AttributeError: 'module' object has no attribute 'indexes'

So reuse old version 0.19.2

version 0.25.3 is not python2 compatible.

Use version 0.24.2 as it is compatible with both python2 and python3.7
(even though we have no reason to use python3.7 nowadays).
See https://pypi.org/project/pandas/0.24.2/

This is a followup of 0d717989