apache-frontend supports correctly ssl_proxy_ca_crt for ssl-proxy-verify,
thus show it in test, still keeping expected 501 reply for caddy-frontend.

The schema shall be https, not http. It got undetected, as caddy-frontend
dies really fast with 501, while apache-frontend is able to communicate
with the backend.

As result of copying nginx configuration from apache-frontend, it was
NOT adapted to Caddy behaviour. Thus make it so, with catch-all apporach
as in Caddy.

Also update test data, as access logs for main nginx instance is now available.

As sources URL depends on the branch, update it to correct one.

 * add switch-softwaretype from review
 * add graceful scripts improvement
 * inform about certificates in tests with explanation
 * add about improving test infrastructure

It is superseded by caddy-frontend

stack for Caddy software will appear later.

As there is some kind of "collision" with request, allow to override
parameters.

Treat `<key>` as default and overwrite it with `frontend-config-<num>-<key>`,
instead of having the global `<key>` always passed to slaves.

This allows to request the partition with:

  monitor-httpd-frontend=12345
  -frontend-config-1-monitor-httpd-frontend=9876
  -frontend-config-1-monitor-httpd-frontend=8765

jinja2 template is required, as some paramters might come from the network.

Removing 'secure' from cookie send by backend is plain wrong.

It is used internally for communication between backend and the server.

mpm-watchdog promise is not applicable for Caddy.

404 is served with notfound.html

Those kept are backward compatibility variables from the request.

Caddy is able to bind only to all or one interface
( https://github.com/mholt/caddy/issues/864 )

By using 6tunnel this limitation is workarounded, and in the result listen on IPv6.

Also drop needless "ipv6" keys across configuration.

As the the feature ssl_proxy_ca_crt is not implemented serve immediately
501 Not Implemented.

As the the feature ssl_proxy_ca_crt is not implemented serve immediately
501 Not Implemented.

%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.

Features:

 * shared place for Caddy configuration
 * gather a lot of parameters for caddy executable, as dislike Apache
   Caddy is configured from command line
 * dummy vhost for example.org
 * challanges (ACME SSL) are disabled
 * bind to interfaces are done per site
 * cache access is dummy, but working
 * /server-status redone in Caddy style
 * antiloris dropped, as this is apache specific
 * apache_custom_http and apache_custom_https
 * dropped not needed leftover access-control-string and protected-path
 * nginx replacement added
 * bin/caddy-wrapper is provided in order to allow parameterization of caddy
   over the network
 * access to log files over http is provided
   * username on log access is consistent, it is not uppercased like it was
     originally on apache-frontend
 * list of TODOs in TODO.rst

This will make it easier to track changes.

Based on caddy-frontend tests

Features:

 * forcediphttpsadapter for SNI
 * compatbile with apache-frontend SR
 * local server to test against
 * supervisor state checks
 * promise list checks
 * test data (to save/load textual assertions)
 * own root CA for HTTPs backend

Based on Jerome's work from /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

proxy.timeout is provided

In order to follow proper way, move caddy to the component and reuse it.

  The webrunner user don't necessary uses webrunner to develop slapos,
  he can use webrunner to develop a new component, where instance is never
  created.

  If the software release don't instantiate instances, skip from continue and consider
  the restauration job done (data is copied, software is built).

 Once the requests to cloudooo software types were removed,
 orphan instances might be kept arround due a lack of implementation
 of garbage collection on slapos proxy.

 This change allows the ghost cloudooo instances, don't fail, until
 the garbage collection implementation be deployed, reducing the
 number of irrelevant failures on resilience after an upgrade.