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.