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.

 - make cloudooo services use same name as in haproxy, this was off by one (service cloudooo-0 was cloudooo_0 in haproxy)
 - test cluster functionality (to catch bug from nexedi/cloudooo!29 )
 - update cloudooo with that fix
 - make sure we set an existant locale ( by using `C.UTF-8` ) and exercice a bit conversions involving characters encoding

See merge request nexedi/slapos!975

The "30" was not removed by mistake, which lead to activity timeout being 30,
instead of configured one.

See merge request nexedi/slapos!977

see cloudooo@0b5ff71a

So that the service names match the backend names in haproxy

Libreoffice needs to run with an UTF-8 locale, otherwise it does not use proper
encoding for text files.
cloudooo sets a default locale as a fallback, but using en_US.UTF-8, which is
not always present (it is not present on capri testnodes). Anyway, this kind
of configuration is the job of slapos, so we prefer to have it done at slapos
level.

- pins component/fluentd gems version to fix :

  ERROR:  Error installing fluentd:
	msgpack requires Ruby version >= 2.4.

  encountered while supplying software/fluentd in a SlapOS Webrunner.

- removes outdated gem arguments '--no-ri --no-rdoc'
  by default `rubygemsrecipe` uses '--no-document' (see https://lab.nexedi.com/nexedi/rubygemsrecipe/blob/master/rubygems.py#L206)

- splits `gem-options` arguments to fit the README example (see https://lab.nexedi.com/nexedi/rubygemsrecipe/blob/master/README.rst#L50)

- adds minimal test to check fluentd SR instanciation

https://mesonbuild.com/

The keyboard option is actually not recommended in the QEMU
documentation
(https://manpages.debian.org/buster/qemu-system-x86/qemu-system-x86_64.1.en.html).
After some tests, it appears that noVNC is already sending raw keyCode
to QEMU since 2016 (see
https://github.com/novnc/noVNC/commit/f4f4e8993d6daeb43b957766cd6973993232ba13).

More information can be found in
https://github.com/novnc/noVNC/issues/21 and
https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/