Those kept are backward compatibility variables from the request.

Do not upper filenames nor users, use them as is.

As SIGUSR1 nor SIGUSR2 can't be used to reload caddy after anything changed
in the wrapper, limit the amount of parameters send to Caddy.

bin/caddy-wrapper is not supported by signals sent to running caddy process.

Transmit default setting to each slave, as there the decision
about serving or not HTTP2 happens.

As Caddy might always serve HTTP2 sites force it to always being able to
serve such sites using HTTP2.

Then per site check what is the default, and enable/disable HTTP2.

As infromation passed to caddy-wrapper comes also from the network it
has to be templated using jinja2 in order to dump variables correctly.

By using 6tunnel workaround Caddy limitation of binding to only one
interface and in the result listen on IPv6.

Also drop needless "ipv6" keys across configuration.

If url is missing, the generated files shall be correct.

It requires a bit of changes into the template logic, as more
information has to be passed to each slave.

Based on caddy-frontend tests

Dummy site is setup for Caddy to run.

This partially reverts commit 863507174c1c3c0365bfa35a7cf298a516b5946d.

Only instance part for nginx is kept, thus Caddy can start replace it.

%2F%2F is used to avoid double slashes cleanup with Caddy. See
https://github.com/mholt/caddy/issues/1298, which touches the problem,
but not enough for zope.

It is dummy vhost for example.org

Caddy, dislike apache, uses a lot of parameters on comand line instead of
Caddyfile, so move them there.

As caddy is quite hard configured from command line, create share place to store
the configuration.

Preparation for Caddy.

This will make it easier to track changes.

Features:

 * forcediphttpsadapter for SNI
 * compatbile with apache-frontend SR
 * local server to test against

Based on Jerome's experiment from
https://lab.nexedi.com/nexedi/slapos/blob/master/software/proftpd/test/utils.py

Main changes:

 * tearDownClass is called in case of errors in setUpClass (mimic addCleanup
   instance method)
 * the setUpClass is split to smaller methods for ease of further development
 * full instance path is exposed for test introspection
 * software path of master partition is exposed for test introspection