We have two public cloudooo instances, https:///cloudooo.erp5.net/ and
https://cloudooo1.erp5.net/ but the software release uses only the first
one. This changes to use both instances by default, in a random order.
This happens for the ERP5 instance and also for the test runner.

This also includes a breaking change: the parameter is renamed from
`cloudooo-url` into `cloudooo-url-list` and instead of being a coma
delimited list of URLs, this is now a proper list of URLs.

Some obsolete code and comments about the old `erp5-cloudooo` partition
that used to part of ERP5 software release have also been removed.

On testing side, ZopeSkinsMixin._setUpClass is changed be made more
robust, by waiting that all activities are processed and using a new
xmlrpc client in every iteration ( to prevent issues like the one from
https://erp5js.nexedi.net/#/test_result_module/20230107-548523A7/10 )

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

The NEO/go commit kirr/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 !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 !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

This is a followup of 02fad6a8

This is a frontend used to provide information about various aspect of the
master instance status, like rejected slaves, failed failsafe slave
publication and maybe more.

Due to various reasons there might be an error while publishing information
about a slave, and such error would end up with stopping the processing of
the partition. This is undesired effect, thus switch to publish_failsafe style
in order to continue processing.

Publish only for active slaves.

Empty extra_slave_instance_list is a leftover of never fully working approach
of slaveless caddy-frontend implementation, so just drop it.

See merge request nexedi/slapos!1280

In some contexts it's required to not stop buildout processing on publishing
errors, thus such recipe is required in those cases.

By providing -error-status-file it's possible to check status of the publish,
the file will be created on error and removed on successful call or during
uninstall. It's responsibility of the caller to handle such errors, for example
by using proper promises.