Create an informative route /health that can be used in health checks

[bschmalhofer]

Give some indication that the web server is alive. This could also be used by the Docker Compose health checks.
See also:

• Healthchecks for OTOBO docker image otobo-docker#12
• https://medium.com/glovo-engineering/meaningful-web-service-health-checks-e975321ac229
• https://inadarei.github.io/rfc-healthcheck/#name-status-3

See also RotherOSS/otobo-docker#12 .

Elasticsearch does not follow the above guide lines and emits the following:

otobo@fbf22e14524c:~$ curl -v -s -f http://elastic:9200/_cat/health
*   Trying 172.18.0.3:9200...
* Connected to elastic (172.18.0.3) port 9200 (#0)
> GET /_cat/health HTTP/1.1
> Host: elastic:9200
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-elastic-product: Elasticsearch
< Warning: 299 Elasticsearch-7.16.2-2b937c44140b6559905130a8650c64dbd0879cfb "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.16/security-minimal-setup.html to enable security."
< content-type: text/plain; charset=UTF-8
< content-length: 66
< 
1648550638 10:43:58 docker-cluster green 1 1 6 6 0 0 0 0 - 100.0%
* Connection #0 to host elastic left intact
otobo@fbf22e14524c:~$ 

[bschmalhofer]

I'm not sure whether leaking status information is a good thing. So let's just add the route health with dummy content. That rounte can be used in health checks instead of the currently used route robots.txt .

[bschmalhofer]

Route has been added, but it is not yet used in healthcheck. Closing this issue.

[bschmalhofer]

Moved to the mile stone to OTOBO 11.0.1 because the feature is included there.