So far, we have used TLS certs from eurac's IT. Now, we (re-)use k8s
infrastructure (in particular the kube-lego add-on) and let kube-lego
- request/renew TLS certificates
- manage the certificate within a k8s secret
We then make this k8s secret available to our nginx and configure nginx
to use it.

We also got rid of internal TLS communication between ingress and the
apps avoiding the necessity to (re-)create valid/self-signed certs. The
overhead seemed unnecessary.

Note: using HTTP(!) over port 443 for internal communication (Shibboleth mishap)

Fix #62

Startup time can be really abysmal: Almost 600s for loading the image
(on a fresh node) and some time to run the initial setup.

Address #60

We noticed the subprocess that runs our 'cron' sometimes quits silently;
one possibility we see is that OOM kills it. In any case, we now also
check for the existence of the commands `sleep` or `timeout` in the
process table (`ps`) via the `livenessProbe`.

Address #60

Found two lines in robots.txt at UFAL's installation that seem ok. Add
also to our stash:
```
Disallow: /repository/*allzip$
Disallow: /repository/oai/requeststripped
```

Lately, we encountered hick-ups when the dspace container comes up but
the postgres container is still missing (although the containers will
restart until both start in the right order).

Here we add one `initContainers` that will poll the postgres db until
success.

Address #60

We use `timeout` from the coreutils package (should be part of many basic
installations - maybe with a different name) to force the individual
healthcheck commands too exit after a predefined timeout (300s); if this
doesn't help, send a SIGKILL.

This should help with the initial problem of hanging. A next step should
be to catch the `timeout` invoked exit and log this as an exceptional
happening.

Address #60

Instead of an external CronJob pod, or a supervisord cron daemon, we use
a subshell. Also we assume, the regular cronjob *also* needs to run when
the container starts. Insofar, we start the subshell, make sure it runs
a single time (and continues in the background) and then continue with
starting clarin-dspace.

Address #48

'502 Bad Gateway' errors from the k8s ingress server can be solved
(sometimes) by restarting the nginx pod. Here we check
https://clarin(-dev).eurac.edu:443

Addresses #53

- fixed some issues with Deployment Guide