In "caddy-frontend: Improve generated files" ssl_ca_crt was mistakenly used
for client authentication, which is in reality not supported nor needed.

It came from misunderstanding of apache configuration.

custom_domain and server-alias on given slave do not have to clash, and
can be deduplicated during request parameter analysis.

/reviewed-on nexedi/slapos!444

Since caddy-frontend: Support wildcards the wildcards are supported.

server-alias and custom_domain can be wildcards, so support such case.

/reviewed-on nexedi/slapos!446

The assertion was fixed incorrectly.

By setting maxDiff to None the test failures are more explanatory.

authorised --> authorized

Because of checking slave id in a whole string, slaves which shall not be
authorized has been put on authorized list.

Example: -frontend-authorized-slave-string == "custom_http",
         slave_id = "custom" has been authorized.

As test_https_url proves, the separation of url and https-url is correctly
implemented.

The case where test runner is not enabled got broken in
2a457867

This time, we had test to prevent regression.

/reviewed-on !440

So that it renders correctly on https://pypi.org/project/slapos.cookbook

I checked with :
 * `python setup.py checkdocs`
 * `python setup.py check --restructuredtext`

as described on https://stackoverflow.com/questions/16367770/my-rst-readme-is-not-formatted-on-pypi-python-org

/reviewed-on !441

we are using trafficserver nowadays, varnish recipe is deprecated

with minimal tests to reproduce the issue that instanciation is broken
when no test runner.

note that we don't put tests in "one big test.py", but from the
beginning we separate so that we can put test for each software type in
test/test_$(software type).py and test for default software type in
test/test_erp5.py

The case where test runner is not enabled got broken in
2a457867

With executing assertEqual(expected, given) the results, especially with
dicts or multiline strings, are more readable in case of failure.

As now the signature is parameterized (in the case of the webrunner),
computing the signature may require not-webrunner-based tools (like
a binary belonging to the SR. Then it can only be done on the
export and the import.