If a server reboots brutally, there will be a legacy httpd pid file stay
in the file system, and the OS may reuse the PID that remains in that
file, which will cause httpd service to fail to start even if there is
no such httpd service is running.

This commit implemented the following logic:
0. If there is no existing PID file, then run the httpd service directly
1. If the PID file exists and contains the PID used by another process,
we delete the PID file, then restart the httpd service
2. If the PID file exists and contains the PID used by another running
httpd service, we allow the httpd report the "already running" error
normally

- activate cu_config_link parameter
- update cu-config.xml
- add supervision log and nc session log

This "simple" approach of using LD_PRELOAD to inject errors when using
inotify no longer works on glibc 2.34 and it's now much more complicated,
as we can see in discussions from https://stackoverflow.com/questions/15599026/how-can-i-intercept-dlsym-calls-using-ld-preload
or code from https://gitlab.com/torkel104/libstrangle/-/commit/720f0ba2ce4423ce5f3e7ebe135e126007365bac

This test was for reproduction of a very specific problem that does not
happen so much on modern linux which has a much higher limit of inotify
watches, the easiest is to remove this test now.

Promise from a8271791 (stack/erp5: new promise to check software
release URL of zope instances, 2020-12-04) was never executed. Adding
the section seemed to be change timing to make the upgrade test, but
this was not correct to not run the promise.

For more detail see discussion on
nexedi/slapos!1414 (comment 189341)

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

See merge request !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.