Use maximum between liveness and readiness for fail_time

[herodes1991]

#195

[oyvindio]

It is possible that I don't have all the details, but based on my current understanding of the issue in #195 , it seems to me like the changes in this PR as it currently is could have some potential drawbacks:
ReadyCheck tries to set a timeout based on the expected duration of a successful rollout at the Kubernetes level. During a rollout it is necessary to wait for initial_delay_seconds from the readiness probe for each pod to be ready, to ensure there are always some number of available pods. As far as I understand, the rollout process does not wait for initial_delay_seconds set on the liveness probe, because this probe's default state is success.
This means readiness probe initial_delay_seconds influence rollout duration directly, but the liveness probe initial_delay_seconds setting to my knowledge doesn't. Because of this difference, it seems to me like a ReadyCheck timeout set based on liveness probe initial_delay_seconds would not necessarily be a good estimate of the rollout duration. Even if the value of initial_delay_seconds on the liveness probe is higher than the same parameter on the readiness probe, the way I see it, a longer timeout isn't always better because it means it takes a longer time before the FAILED result is set on the application status if the rollout fails, and the user deploying the application can get feedback about that.

[herodes1991]

I agree with you @oyvindio, the only weird thing is that we had a scenario where the deployment was successfully deployed but the FIAAS application was marked as FAILED 😔. I will close it for now and encourage our users to increase the initial_delay to be more "flexible" 😄