This reverts commit 31eaaec1a2bd8bc8648a686a83be989a9615a93e.

This slows down business template by a factor of two and it seems we
don't need it. I'm experimenting with hacks in ppml.py but maybe just
creating the Unpickler with encoding='utf-8' in
product/ERP5Type/XMLExportImport/__init__.py:267 is enough ?

at this point they all fail after long timeouts, because neo does not
support py3 yet

see 2a457867 (erp5: Rework testrunner's HTTP server, 2018-09-04), with
python3 the timing is not same and sometimes the parameter was not
propagated before root partitions promise were all solved, this add a
promise at the root partition to ensure the parameter is propagated

Not sure why it was OK on python2 and not sure if this has to be done
or the promise code needs to cast the results of getConfig()

Otherwise it fails with the following exception because of non-ASCII characters
(`[A-Z&é@{]{3,7})`) (see unconvert()) below):

  => erp5_core/PathTemplateItem/portal_preferences/default_site_preference.xml
     File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 844, in load
        dispatch[key[0]](self)
     File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 1035, in load_short_binstring
        self.append(self.decode_string(data))
     File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 989, in decode_string
        return value.decode(self.encoding, self.errors)
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 19: ordinal not in range(128)

This reverts commit 6c399134.

https://github.com/rust-lang/cargo/issues/7169

https://doc.rust-lang.org/nightly/cargo/commands/cargo-install.html#dealing-with-the-lockfile

See merge request nexedi/slapos!1414

See merge request nexedi/slapos!1413

This reverts commit 9497c734.
This reverts commit c55337f2.

This causes other build failures on some environments.
Turns out, this was not even enough to get gcc to fully build on my
environment, so more fixes are needed.

Most tests were unaffected by partitions now having different IPv6.
The main issue is that there is now a .slapos-resource file in each
subpartition as well, same as in normal top-level partitions, which
interferes with a hidden behavior of slapconfiguration recipe that
allowed a kvm in a subpartition to transparently use the tap of the
top-level partition. Now we need to explictly take this tap and put
it in the .slapos-resource file of the subpartition.

Since slapos.core!515 services of stopped instance do not appear in
supervisord anymore.

The test depended on the partition's address list ordering IPv4 before
IPv6. This was an unspecified, undocumented behavior of slapos format
that standalone 'broke' when it started using IPv6 range. This changes
the test so it doesn't rely on this behavior anymore.

Properly reset forced instance processing flag (whether `--all`) to
its previous value after forcing it to true in some resiliency tests.

When IPv6 range is be enabled in testnodes, `_ipv6_address` does not
contain a single IPv6 address shared by all partitions anymore, but
instead the IPv6 range from which each partition will obtain its own
IPv6 address. Instead there is now `computer_partition_ipv6_address`
which contains the IPv6 address of the main partition.

This change blindly replaces all occurences of `_ipv6_address` with
`computer_partition_ipv6_address`, since that will fix most simple
cases. The remaining cases, such as tests with instance trees that
use multiple partitions, can be investigated and fixed individually.

Avahi was not buildable on Debian 11.

These md5 changes come from unrelated changes.

Fixes building gcc-8.5.0 on libc6 version 2.36 (at least).
Fixes this error:
  configure: error: in `.../parts/gcc-8.5/.build/gcc-8.5.0':
  configure: error: C compiler cannot create executables
  See `config.log' for more details.
relevant config.log extract:
  configure:4326: gcc   -Wl,-rpath=.../parts/gmp/lib -Wl,-rpath=.../parts/isl/lib -Wl,-rpath=.../parts/mpc/lib -Wl,-rpath=.../parts/mpfr/lib conftest.c  >&5
  .../parts/binutils/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'

because this metabase now needs SNI properly configured, which means
that the backend must know the frontend domain name and can not be
accessed by its IP address, we stop serving https on IPv6 directly from
metabase's embedded jetty and reconfigure it to serve http on IPv4 and
add an haproxy instance to serve https on IPv6. This is just an
"internal" change because the external IP will be same and the
certificate is still a self-signed one for now.

references:
 - https://github.com/metabase/metabase/issues/29660
 - https://discourse.metabase.com/t/http-error-400-invalid-sni-when-upgrading-from-0-45-3-to-0-46-0/24599/8