Since da03653908aea9a62f805faf0328f7b2f046abaa slapos.core's slapproxy transmit
more parameters, so adapt tests to account for it.

The https://bz.apache.org/bugzilla/show_bug.cgi?id=65769 seems hitting
various software releases with strace like:

select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
wait4(-1, 0x7ffe9579eb84, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
times({tms_utime=561, tms_stime=669, tms_cutime=558, tms_cstime=99}) = 3280801757

Also adapt the --with-pcre switch in order to find the pcre-config during the
build process.

This prevents errors like:

Error while executing:
/srv/slapgrid/slappart54/t/dau/shared/git/f7efae57344573a59b9e441431a34e9a/bin/git ls-remote -h -t git://github.com/qunitjs/node-qunit.git

fatal: remote error:
  The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

In slapos.core commit 425f5bb7b (slapgrid: replace platform.linux_distribution()
with distro.linux_distribution(), 2022-03-21), a dependency to distro
was introduced. Because tests run with slapos.core fetched from git, they
already started to fail because of the missing version pin.

The pin is made to the latest version for both python2 and python3.
Usually we take the latest version compatible with python2, but I just
thought this way was probably better.

I think we don't want trailing whitespaces anywhere in this repository

This reverts commit e1dae860.

Despite of microupgrade, there are problems with compiling this version.

Via header for response and request is fully stabilized and present according
to the RFC now.

Important information, like protocol and protocol version are exposed.

Hops which were present in the request are stored and descriptively named.

Versions of components are exposed in hidden way and in the same time the
frontend administrator and frontend user are able to analyze the versions,
and the version history present on the node is transmitted back.

Additionally each node can be identified by frontend admins and users for
request and response headers, allowing more debugging.

Improve the tests by extending assertSlaveBase and reuse it instead of
duplicating the code everywhere.

Accessing headers.dict results with dropping headers sent in more then one
line, which is accepted by RFC.

So in case if many lines for given header arrived, expose them as a list,
otherwise simply show exactly arrived header.

Rapid.CDN has strong requirements regarding Via header passing by, so strip
down unnecessary parts of the original implementation.

The former ftp.pcre.org FTP site is no longer available,
use sourceforge instead, see https://www.pcre.org/

The https://bz.apache.org/bugzilla/show_bug.cgi?id=65769 seems hitting
various software releases with strace like:

elect(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
wait4(-1, 0x7ffe9579eb84, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
times({tms_utime=561, tms_stime=669, tms_cutime=558, tms_cstime=99}) = 3280801757

Also do micro upgrade from util-linux 2.37.1 to 2.37.2, which was in
component/libuuid.

See merge request nexedi/slapos!1130

The test name (and shared instance name) was misleading.

The test have incorrect leftover of old limited implementation, now the system
shall update images by itself.

Also the typical scenario - image on first request - was not covered.

Adapt the test to code without needed linking.

image-download-controller raises error state during download process, to
inform other components that download is not ready yet.

template-kvm-run.in asserts presence of all images and otherwise refuses to
start, so that it gives chance for the image to being downloaded.

Sorting images happen by proper key instead of needless links.

Fix race condition, as the hash parameter shall depend on boot image url
configuration, and not it's failure state.

Cleanups:

 * simplify nginx management with real template
 * rename sections to provide explanation in their name so it's less cryptic

Instead of trusting CSR id published by the node which tries to join the
cluster add a tool which is able to compare exposed CSR with one in caucase
and then decide to accept node in the cluster. This tool does what usual user
would do, and it's logic implemented as a script leads to much simpler profiles.

For sake of clean profiles csr_id has been removed, except when it's used for
self joining of the user to the cluster.

Adjust paths.
Cleanup.

Use relative paths. Cleanup.

CSR id shall be requested only when it's not available yet, as otherwise it
contacts caucase server needlessly, and in some circumstances it can result
with bogus new CSR.