use hash-existing-files feature of wrapper recipe to make
sevices restart automatically when they are re-requested with different
parameters.

If key or csr are already present, we should not re-run this
openssl command which generates a new key and a new CSR.

Caucase rerequest uses a CSR *template* and use it to generate
a new CSR with a new key, so we should not use the actual key to
generate this CSR, because it is caucase rerequest job to generate
the key.
Also, we should be careful not to generate a new CSR every time this
command run, otherwise a new key will be generated and a new CSR will
be sent to caucase, but caucase will not sign it automatically (since
we configure it to sign only one certificate).

This means that the case of IP address changes is currently not
supported automatically. To support it we would need to:
 - force generation of a new CSR template
 - force caucase rerequester to request a new certificate (by removing
  existing certificate)
 - force caucased to sign the new certificate

This commit fix indentation and remove simplefile macro that is no longer used

The test expecting that X-Forwarded-For is empty can also accept the
case where X-Forwarded-For header is not present.

Make the value and its changes easier to read.

Revert f8f72a17 ([erp5] don't use caucase generated certificate for now, 2019-03-12) since nothing prevents us drom using caucase certificate now.
 
Use [managed resources](nexedi/slapos.core!259) to simplify existing tests and introduce tests for:

## Access Log

 - [x] balancer partition should produce logs in apache "combined" log format with microsecond timing of requests.
 - [x] these logs should be rotated daily
 - [x] an [apachedex](https://lab.nexedi.com/nexedi/apachedex) report is ran on these logs daily.

## Balancing

 - [x] requests are balanced to multiple backends using round-robin algorithm
 - [x] if backend is down it is excluded
 - [x] a "sticky cookie" is used so that clients are associated to the same backend
    - [x] the cookie is set by balancer
    - [x] when client comes with a cookie it "sticks" on the associated backend
    - [x] if "sticked" backend is down, another backend will be used

## Content-Encoding

 - [x] balancer encodes responses in gzip for some configured content types.

## HTTP

 - [x] Server uses HTTP/1.1 or more and keep connection with clients

## TLS (server certificate)

In this MR we also change apache to use a caucase managed certificate and add test coverage for:

 - [x] balancer listen on https with a certificate that can be verified using the CA from caucase.
 - [x] balancer uses the new certificate when its own certificate is renewed.

But we don't add support for:
 -  ~~balancer can be instantiated with a certificate and key passed as SlapOS request parameters (code [here](https://lab.nexedi.com/nexedi/slapos/blob/757c1a4ddee93659d5e2649e4252d87bf9494566/stack/erp5/instance-balancer.cfg.in#L208-213))~~ this use case is the job of caucase, so we no longer support this.

## TLS (client certificate)
 - [x] balancer verifies frontend certificates from frontend caucases ( also tested in "Forwarded-For" section )
 - [x] if frontend provided a verified certificate, balancer set `remote-user` header
 - [x] balancer updates CRL from caucases ( `caucase-updater-housekeeper` )
 - (NOT TESTED) balancer updates CA certificate from caucase ( `caucase-updater-housekeeper` ). Since this is would be complex to test and basic functionality of `caucase-updater-housekeeper` for frontend caucases is covered by CRL test, we don't test this for simplicity.

## "Forwarded-For" header

This was also covered by existing tests:  

 - [x] balancer set `X-Forwarded-For` header when frontend certificate can be verified
 - [x] balancer strips existing `X-Forwarded-For`

## Integration with the rest of ERP5 software release

This was also covered by existing tests:  

- [x] The https URL of each Zope family is published and replies properly
- [x] Some https URLs are generated for `runUnitTest`, so that test run with an https certificate. This is also covered by regular ERP5 functional tests.

See merge request nexedi/slapos!840

See merge request nexedi/slapos!839

https://github.com/eclipse-theia/theia/blob/v1.7.0/CHANGELOG.md#v170---29102020

Future Cython+ work will use it.

Fix for #20200514-218C705 - \[testnode\] frontend for log access

Depends on nexedi/erp5!1304

See merge request nexedi/slapos!848

This fixes the nextcloud SR, which was broken by
commit 92779bf4
(mariadb is not a part anymore).

This fixes commit a62e5e7b.
See also commit 491e6e28.

And set it as log_frontend_url in testnode config

Just add the following 2 lines in a SR:

[mariadb]
location = ${mariadb-10.4:location}

It does not build with GCC 8.2

Going Go1.14.9 -> Go1.14.10 brings in compiler and runtime fixes
including fix for crash in garbage-collector due to race condition:

https://github.com/golang/go/issues/40642
https://github.com/golang/go/issues/40641

Tested on helloworld SR.

See merge request nexedi/slapos!844

validators.url is enough, even for Caddy, to check that URL is correct, and
caddy_backend_url_validator was introduced before validators.

Also calling an external command for each slave takes a lot of time.

Thanks to this other sections can directly reference them, and so they are
correctly created as needed, so linking section does not need update-command

The password is anyway present in the section itself, so it's eventual change
will result with reinstalling the section.

Also change a bit existing frontend_url to manage it the same way.

This way buildout can reuse egg caches and it's a bit faster:

To run a simple instance buildout, from 2.837s it goes down to 1.875s.
To run slapos node instance 10 times just after requesting an ERP5 instance, it goes from ~112s to 98s

before:

    hyperfine "/srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U"
    Benchmark #1: /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U
      Time (mean ± σ):      2.837 s ±  0.275 s    [User: 2.481 s, System: 0.285 s]
      Range (min … max):    2.482 s …  3.222 s    10 runs

after:

    hyperfine "/srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U"
    Benchmark #1: /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U
      Time (mean ± σ):      1.875 s ±  0.067 s    [User: 1.660 s, System: 0.148 s]
      Range (min … max):    1.816 s …  2.038 s    10 runs

See merge request nexedi/slapos!846

Changes configuration files to run repman tests in python3.

Adds the newly added to nexedi's repositories rubygemsrecipe (https://lab.nexedi.com/nexedi/rubygemsrecipe) to the list of tested eggs.

This also fixes rpath of rust binaries.

See merge request nexedi/slapos!845

Since 0.9.6 caucase stopped using the 128bits OID arc that caddy/golang does
not support, so nothing prevents us from using a caucase certiciate now.