Before this commit, the Go workspace was always activated before
launching the Theia shell and starting the embedded supervisord.

This in turn added the gcc installed by Theia to the PATH, meaning
that nested instances would be compiled with Theia's gcc instead of
the system gcc, making the compilation outcome dependant on Theia.

With this commit, the gcc resolved by PATH is now the system one.

See merge request !987

This option takes a string representing a valid JSON object and
forwards the corresponding python dict to the embedded instance.

Features:

 * random response is possible of big sizes
 * timeout can be randomized

See merge request nexedi/slapos!979

This fixes 157dd7ab.

It workarounds stack/resilient/pbsready.cfg.in directory:backup string
concatenation:

  backup = $${basedirectory:backup}/$${slap-parameter:namebase}

See merge request !981

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/

This defers the rendering of `instance-theia.cfg.in` to the instance
creation time instead of the software installation time, which will
allow buildout sections to be added based on the instance parameters.

See merge request !981

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.