This commit add srsLTE into slapos. More informations about
  srsLTE at: https://github.com/srsLTE/srsLTE

  This still a proof of concept because:

   - Not all dependencies are ported into slapos
   - The configuration files are not turned into parameters
   - enb and epc are running on the same partitions
   - Usage of sudo is a code crime, but it is the only way currently**

** This would require patch the srsLTE, to allow external tools pre-configure
  the environment. ie.: Create network interface.

Use json.dumps/.loads to generate promise plugin code. This is safe as it will correctly escape sring and prevent code injection from untrustable parameters.

Add 'import' parameter to simplify parameters used to generate the script instead of passing full import code. When import parameter is set, promise will be loaded from that import path and parameter `content` is ignored.

/reviewed-on nexedi/slapos!515

Close the NBD socket when testing it so it won't mess up qemu.

/reviewed-on nexedi/slapos!516

- Add `buildout.hash.cfg` file so this way we can use the useful `update-hash` script
- Refactor a bit the `software.cfg` file sections as it was repeating itself

/reviewed-on nexedi/slapos!512

Extend the backend with Timeout configuration via headers and use it
to prove, that request taking more than try_duration is correctly served.

Also prove that try_duration and try_interval are correct passed to the slave
configuration.

try_duration and try_interval are Caddy proxy's switches which allow to deal
with non working backend (https://caddyserver.com/docs/proxy)

The non working backend is the one, to which connection is lost or was not
possible to make, without sending any data.

The default try_duration=5s and try_interval=250ms are chosen, so that in
normal network conditions (with all possible problems in the network, like
lost packets) the browser will have to wait up to 5 seconds to be informed
that backend is inaccessible or for the request to start being processed,
but only a bit more than 250ms if Caddy would have to reestablish connection
to faulty backend.

In order to check it out it is advisable to setup a system, with real backend,
like apache one, and configure iptables to randomly reject packets to it:

  iptables -A INPUT -m statistic --mode random -p tcp --dport <backend_port> \
  --probability 0.05 -j REJECT --reject-with tcp-reset

Using ab or any other tool will results with lot of 502 EOF in the Caddy error
log and also reported by ab. With this configuration there are no more
errors visible to the client, which come from the problems on the network
between Caddy and the backend.

Assert itself "check_output" of given command, so provide simple
subprocess_output with all possible information from the called command.

Since slapos.core 1.4.16+ slapos proxy is not able to consume or publish
non-strings, which makes tests not working.

Thanks to this 'None' is used in BuildoutSerializer

ZODB/go started to use it in tests:

	kirr/neo@532d014f

It started to be used in fs1/go.

https://github.com/kisielk/og-rek/compare/dd41cde712...8b25c4cefd

- support for persistent references,
- fixes for decoder and encoder,
- allow to specify protocol on encoding,
- support for protocols 3 and 4 including added support for Python bytes,
- package-level documentation.

update pep445 patch using https://raw.githubusercontent.com/vstinner/pytracemalloc/pytracemalloc-1.4/patches/2.7.15/pep445.patch

If qemu use physical disk device instead of created qemu image disk, we skip this promise.

/reviewed-on nexedi/slapos!507

While helping @romain to review my current work we tried to build helloworld and found that it is completely broken.

It was first minimally fixed to pin eggs and the like.

Then I've added Go1.11 to our stack, so that recent-enough compiler/stdlib could be used. A note goes here that currently our lab uses go1.9 which is outdated and not supported by upstream, and other bits are still using go1.10.3 while go1.10.7 was already released some time ago with bug and security fixes. I did not touched neither  go1.10 / nor go1.9, but imho it makes sense for infrastructure people to look into appropriate upgrades.

Finally component/helloweb/ is switched to use gowork infrastructure (see 1b540151 for gowork introduction). Today gowork is used to build eveything go-related, so building go bits manually via cmmi as example is  a bit misleading. Gowork is also required in case we'll need to use any third-party or our package a helloweb-go.

/cc @luke, @alain.takoudjou
/reviewed-by @jerome, @tomo
/reviewed-on nexedi/slapos!505