Unfortunately real world deployment is using iptables, which is not consistent
regarding the port advertised to in case of UDP, thus it's required to force
the user to set the "virtual" listening port.

It's based on phased out caddy-frontend, especially as next step is to drop
Caddy software from the software release.

Configuring failover URL and being able to rely on cached content is not so
simple, thus document the requirement and prove in test, that such
configuration works correctly.

caddy-frontend-N is bad name, it's just frontend-node-N.

instance-slave-caddy-simplified-input-schema.json has been removed, as it is
not useful.

By adding failover url the user is able to configure special backend to use
in case if the real backend is down.

Original PoC was done by Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>.

It does -X PUT + --data-binary @file.

Improvements:

 * link from README to schemas
 * drop incorrect entries in README
 * improve entries description in README
 * make parameter description more understandable in SCHEMA

backend-active-check is really long and technical name, whereas health-check
is well known description of backend checks.

The public-ipv4 comes from the historical usage of the system, but since
new implementation came into place it was never needed, so now it's time to
say goodbye.

Test has been updated to do in-house mimic of the used IP to access.

On backend side headers are asserted in tests:

 * X-Forwarded-For
 * X-Forwarded-Proto
 * X-Forwarded-Port
 * Host

In order to pass cleanly X-Forwarded-For from the frontend to the backend,
it's passed as X-Forwarded-For-Real in case of cached slaves.

Noted problem with IPv6 endpoint was used, as in this case 6tunnel IP would
be used.

QUIC is not used at all, and became superseded by HTTP/3

Customized configuration support is not used since introduction of
Caddy software, so there is no need to support it anymore.

Based on current experiences, update the documentation regarding iptables
and network capability documentation.

URLs to generate authentication and to upload keys uses self-signed
certificates, which can't be verified.

There is no need anymore to have two processes for normal and nginx slaves,
as nginx ones are served by caddy anyway.

Also inform the requester that type:eventsource is not implemented.

This reverts commit 7993ff81.

Custom configuration checks are hard to be trusted, as they can impact too
many aspects of running frontend.

Frontend administrator knows the risks of custom configuration, and shall take
proper care.

/reviewed-on nexedi/slapos!543

Use KeDiFa to store keys, and transmit the url to the requester for master
and slave partitions.

Download keys on the slave partitions level.

Use caucase to fetch main caucase CA.

kedifa-caucase-url is published in order to have access to it.

Note: caucase is prepended with kedifa, as this is that one.

Use kedifa-csr tool to generate CSR and use caucase-updater macro.

Switch to KeDiFa with SSL Auth and updated goodies.

KeDiFa endpoint URLs are randomised.

Only one (first) user certificate is going to be automatically accepted. This
one shall be operated by the cluster owner, the requester of frontend master
partition.

Then he will be able to sign certificates for other users and also for
services - so each node in the cluster.

Special trick from https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
is used for one command generation of extensions in the certificate.
Note: We could upgrade to openssl 1.1.1 in order to have it really
simplified (see https://security.stackexchange.com/a/183973 )

Improve CSR readability by creating cluster-identification, which is master
partition title, and use it as Organization of the CSR.

Reserve slots for data exchange in KeDiFa.

/reviewed-on nexedi/slapos!518