This endpoint aggregate all checks related to <service id> on the agent
and return an appropriate http code + the string describing the worst
check.

This allows to cleanly expose service status to other component, hiding
complexity of multiple checks.
This is especially useful to use consul to feed a loadbalancer which
would deleguate healthchecking to consul agent.

Exposing this endpoint on the agent is necessary to avoid a hit on
consul servers and avoid decreasing resiliency (this endpoint will work
even if there is no consul leader in the cluster).

Fix hashicorp#2488, relates to hashicorp#802

Change-Id: Ib340c62bbbba46fd4256ed31474d8ffb1762d4df
Signed-off-by: Grégoire Seux <g.seux@criteo.com>

Moved /v1/agent/health/service/<service_id>, becomes
/v1/agent/health/service/id/<service_id>

Added /v1/agent/health/service/name/<service_name>

This endpoint fits better with load-balancing use-cases, since most LB
configuration schemes defines unique healthcheck URI(s) per "backend/service"
object, or imply custom patches / bad performance workarounds, etc.

The tradeoff with this second endpoint being that if two instances of a same
service sits on the same node, they will be both marked as warning/critical.

Signed-off-by: Pierre Cheynier <p.cheynier@criteo.com>

…der to fix unit tests

…x unit tests

…x unit tests

connect/ca: rework initialization/root generation in providers

…x conflict