runTestSuite.in uses _update_hash_filename_ compatbility to avoid clash with
section's filename key.

As software.cfg is extended by other software releases rename the template
part to template-neo in order to avoid clash of sections.

instance.cfg md5sum has been omitted.

_update_hash_filename_ key is used to avoid clash with recipe.

hexagonit.recipe.download is replaced with slapos.recipe.build:download in
order to have the same approach everywhere and so _update_hash_filename_ key is
used to avoid collision with section:filename.

Use _update_hash_filename_ to avoid filename clash with recipes.

_update_hash_filename_ is used to avoid conflict of section:filename key with
hexagonit.recipe.download

A lot recipes treats filename key as something special, so for them support
additional key _update_hash_filename_, in order to avoid such clash.

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