In 95c05120, a published parameter "ssh-url" was added
to the webrunner, clashing with the existing "ssh-url" parameter used by the resilient
stack (which is extended by webrunner).
As the new "ssh-url" is public and read by customers, it doesn't make sense to rename
it to something more slaprunner-ished, more especially it already existis "ssh-command",
so if a second parameter was named "runner-ssh-url" it wouldn't make sense to the user...

This change had to be propagated to all the software releases extending the resilient stack.

Finally, I think that stacks should use namespaces to avoid conflicts with the software
releases extending them. Currently, we are doing the opposite and are using namespaces
for software release to avoid conflicting with their stack : for exemple, in stack/resilient
we have a section [sshd-raw-server] and in the software/slaprunner we have [runner-sshd-raw-server].
This situation will create clashes when one software release extends 2 stacks, as nothing
guarantees that 2 stacks have no conflicting section name, config file path, ...

This test just update slave dict of the class, so it is needed to request.

As timeout is the same on frontend caddy, ATS and backend caddy allow
0 or 1 accesses to the additional endpoints. The request might not reach
the backend caddy, and this is expected.

/reviewed-on !647

It is not part of the tested system.

The test system requires to adapt to changes in slapos.core rapidly,
and so it has use the most recent version.

Sometimes we observe:

    /usr/bin/ld: cannot find -laspell
    collect2: error: ld returned 1 exit status
    libtool: install: error: relink `email-filter.la' with the above command before installing it
    Makefile:960: recipe for target 'install-filterLTLIBRARIES' failed

/reviewed-on !652

QEMU has troubles if host runs on XFS, which is already fixed upstream:

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b2c6f23f4a9f6d8f1b648705cd46d3713b78d6a2

But as new release is not there qemu-kvm is fixed like distributions do:

https://bugzilla.redhat.com/show_bug.cgi?id=1751934#c22

/reviewed-on !650

Due to missing test and rare condition, if https-only and
prefer-gzip-encoding-to-backend were true accessing http:// of the
slave resulted with redirecting to the https:// url with prefer-gzip
added to the path, which is fixed and tested here.

 * improve test coverage of instance.
 * version up ssh (for no special reason)
 * other minor fixes

/reviewed-on nexedi/slapos!629

/reviewed-on nexedi/slapos!634

If slaprunner itself was installed on a slapos which had shared parts
enabled, these shared parts will also be used while installing softwares
inside the slaprunner.

Because ${buildout:shared-part-list} is a multi line property, it was
not possible to generate .cfg files (which needs special handling of
multi-line strings) directly from software buildout (where jinja
templates are not yet available), so we use a trick of generating a
plain text file in software and parsing it during instance.

Instead of having to copy and paste the "ssh command", having a
clickable link is more user friendly. This integrates seamlessly with
ChromeOS secure shell app (eventhough the app does not do anything with
fingerprint as per version 0.19)

Because this slapos often is executed when just running `slapos` at is
in the $PATH, we should also consider special cases where users want to
call this script with another $SLAPOS_CONFIGURATION.

When $SLAPOS_CONFIGURATION is already set, ~/bin/slapos will not change
it, it will only set it when not set.

Because slaprunner might be instanciated in a different directory than
the shell user $HOME (like in recursive SlapOS), it's necessary to set
HOME to the base directory. For "bare metal" SlapOS, this would not make
any difference.

so that terminal uses terminfo from the same curses library.

Also change download URL to use https:// (no reason to use http)
Also switch to git format patch

this is the firefox we are currently using on testnodes. It's useful to
be able to run test with exactly same version to debug issues.

/reviewed-on nexedi/slapos!646

Most important changes:

 * promise tests are dropped, as this is implemented by test case
 * slave is always instantiated, to pass promise checks
 * move out some methods from the class
 * change the way how supervisor is called
 * adapt requestDefaultInstance to request slaves

New test system requires a lot of work for testing some edge cases of
caddy-frontend instantiation, so skip some tests for now.

caddy-frontend cluster stabilises only in case if slaves are present, as
otherwise slapos node instance won't run w/o errors, so request slaves
early.

Nextcloud's redis is causing `AF_UNIX path too long` on test nodes.