// take into account not only maxUnavailable and any surge pods that have been created, but also unavailable pods from
// the newRC, so that the unavailable pods from the newRC would not make us scale down old RCs in a further step(that will
// increase unavailability).
//
// Concrete example:
//
// * 10 replicas
// * 2 maxUnavailable (absolute number, not percent)
// * 3 maxSurge (absolute number, not percent)
//
// case 1:
// * Deployment is updated, newRC is created with 3 replicas, oldRC is scaled down to 8, and newRC is scaled up to 5.
// * The new RC pods crashloop and never become available.
// * allPodsCount is 13. minAvailable is 8. newRCPodsUnavailable is 5.
// * A node fails and causes one of the oldRC pods to become unavailable. However, 13 - 8 - 5 = 0, so the oldRC won't be scaled down.
// * The user notices the crashloop and does kubectl rollout undo to rollback.
// * newRCPodsUnavailable is 1, since we rolled back to the good RC, so maxScaledDown = 13 - 8 - 1 = 4. 4 of the crashlooping pods will be scaled down.
// * The total number of pods will then be 9 and the newRC can be scaled up to 10.
//
// case 2:
// Same example, but pushing a new pod template instead of rolling back (aka "roll over"):
// * The new RC created must start with 0 replicas because allPodsCount is already at 13.
// * However, newRCPodsUnavailable would also be 0, so the 2 old RCs could be scaled down by 5 (13 - 8 - 0), which would then