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 nexedi/slapos!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.

This should fix resiliency tests

/reviewed-on nexedi/slapos!439

So that we can use
nexedi/slapos.core!51

/reviewed-on nexedi/slapos!438

Golang needs a recent enough version of ld (>2.2) and of gcc ( > 5.5 )

This also introduces multiple gcc versions in gcc component, to have finer control over which component uses which version of gcc.

/reviewed-on nexedi/slapos!436

kumofs does not build with gcc 6

When ld version is too old (Debian 7 comes with version 2.2 which is too
old), golang testsuite fail with:

binutils_test.go:237: SourceLine for main: expect [{main /tmp/hello.c 3}]; got [{main  0}]

see also https://github.com/golang/go/issues/26584

We explicitly use gcc 8.2, but what we need is gcc > 5.5 because of
https://github.com/golang/go/issues/24046
When 8.2 (or newer) becomes the default SlapOS gcc, there should be no
problem in dropping the explicit version and using ${gcc:location} here.