This fixes:

  Installing jupyter.
  While:
    Installing jupyter.
    Base installation request: ...
    Getting distribution for 'argon2-cffi'.
  Error: Picked: argon2-cffi = 20.1.0

Addition of argon2-cffi in commit 7d1ea024
was a last-minute change to fix jupyter SR.

Accessing http with path starting with /HTTPS/ would result with 503 responses
from ATS itself.

Test is covering the problem and also asserting that fix does not damage https
access with path starting with /HTTP/

Edggetest monitoring got capability of region definition in each cluster.

In order to stabilise parameter serialisation the json-in-xml has been used.

Slave reference can be dangerous for buildout validity or file names.

Request and publication is switched to fully serialised approach, so that
complex data structures like lists and objects can be safely transmitted.

The requests are backward compatible, so for current and simple usage
automatic region is setup.

Much more information are published to main and shared instances, like
lists of available and assigned regions. Regions can be added and removed,
which will be reflected automatically for the slaves.

Information send to the bot node are minimised to only needed ones.

check-frontend-ip-list can be configured according to the list, and each
element overrides previous one:

 * globally on cluster
 * default per region
 * globally per slave
 * specific per region on slave

Note: It's known that:

 {%-     set base_slave_dict = json_module.loads(slave.pop('_')) %} {#- XXX: Unsafe! #}

      is really unsafe, but for most of usage of monitoring slaves it's
      considered good enough.

Minimize amount of parameters passed from master partition to the slaves, as
slave configuration shall be maximally self contained.

Note: This will allow further development (like regionalization) much simpler.

Since json-in-xml is used, check-http-header-dict shall be simply the JSON
object, no need to express it as a string.

Note: This is request backward incompatible change.

This work results with VM being restarted on parameter change.

The VM will be stopped in case of parameter change, then the system will try
to start it back. For external resources (like downloadable images) it will be
waited until such images are correctly present before starting back the VM.

Image download is done asynchronously with image-download-controller system.

The instantiation will fail, which is expected.

This will minimise amount of needless restarts.

Special care is taken to work with files appearing later, by preparing them as
empty ones.

Covered assets for parameter change are:
 * software release
 * boot-image-url-list
 * boot-image-url-select
 * virtual-hard-drive-url

For sanity virtual-hard-drive-md5sum became mandatory.

virtual-hard-drive-gzipped case is covered.

In older theia versions `~/srv/frontend-static/logo.png` was a symlink
to the actual logo file. Now the logo is copied into `frontend-static`
but a simple `cp -f` does not behave as expected when the destination
already exists and is a symbolic link:
- if the symlink is valid, the file is copied to the symlink target
- if the symlink is broken, the copy command fails

So the destination must be removed before copying.

By using '/lib/systemd/systemd-journal-remote --output=...'
the dump can be converted back to a file that is readable with
'journalctl --file=...'

Given that the default is to use raw for device drives and qcow2 for
file drives,  and that 'discard' was already enabled for raw, this
commit is in practice mainly for file drives, for which QEMU processes
TRIM by punching holes (i.e. the image file becomes sparse).

This reduces disk usage not only by the process running the VM but
also by backups and replicas (e.g. runner1).

For qcow2 at least, the discarded space can be reused for other blocks
and qemu compacts the image at dump (for backups) so images on replicas
are not sparse.

When an image disk format doesn't support it, QEMU ignores the option
so it's safe.

Guest support of TRIM for virtio-blk is recent: Linux 5.0

The user must be aware of any mistake he did. For example, he may lose
time by not understanding why the VM does not behave as expected or by
distorting measures in benchmarks.

The only legitimate reason to automatically fix a parameter is backward
compatibility, if a value is not valid anymore. But such fallback
should only be temporary. There's no such case recently.

At last, it increased maintenance by having to keep the lists of valid
values up-to-date.

About:

  -  if disk_info['io'] == 'native':
  -    additional_disk_options += ',cache.direct=on'

These lines are redundant when cache is none.