Introduce Liveness and Readiness endpoints

[antoinesd]

We should introduce a new "readiness" endpoint to let 3rd party services check if the current service is ready to answer.
Current endpoint will become a Liveness endpoint, but to avoid confusion we should deprecate it and introduce an explicit liveness endpoint.
To sum up the tasks, we must:

• Introduce a /liveness endpoint behaving like current endpoint
• Introduce a /readiness endpoint to expose wether the service is ready to answer to request or not
• deprecate the current endpoint

[Emily-Jiang]

We should keep /heath.

/health endpoint should return the combination of /readiness and /liveness. As cloud boundary can only do one check, which is /heath.
/health should only return true if both /readiness and /liveness is true. Otherwise, it returns false.

[cescoffier]

I disagree on the combination option. For compatibility reason, it should only delegate to the liveness endpoint as it's how it is used Today. If the Cloud infra does only support liveness, then /health and /health/liveness would be equivalent.

Readiness and liveness check can be very different, and the combination would report confusing results.

[Emily-Jiang]

@cescoffier We can discuss this on a call. This issue is a dup of #34 though. Which one should be one?

[cescoffier]

@Emily-Jiang Is there a health check call?

[antoinesd]

I agree with Clement. For backward compatibility we'll keep /health but shouldn't change its behavior.

This issue is a dup of #34 though. Which one should be one?

You mean #35 @Emily-Jiang . Yes you are right : I'll close this ticket and continue discussion in #35.

@Emily-Jiang Is there a health check call?

Nope. I plan to organize a new one.

[antoinesd]

Ticket is a duplication of #35. I'm closing it