Replace CFRoute Valid/Invalid with the Ready condition

[danail-branekov]

Is there a related GitHub Issue?

#3304

What is this change about?

Based on PR #3303

The Ready status condition is becoming the standard for Korifi
resources, therefore let's get rid of the Valid and Invalid
conditions in favour of the Ready one. Thus the CFRoute status
reconciliation code could be significantly simplified as we already have
the readyConditionBuilder utility in place.

Noone seems to care about Valid/Invalid status conditions, noone
cares about the Ready condition as well. However, having a standard
Ready condition is good (see #2098)

While being here, CFRoute.Status.Description and
CFRoute.Status.CurrentStatus are removed (as
again, noone cares) - hopefully this is not an incompatible change. If
anyone ever gets interested whether the route is OK, they should check
the Ready condition instead.

Does this PR introduce a breaking change?

No

Acceptance Steps

No functional change

Tag your pair, your PM, and/or team

@cloudfoundry/wg-cf-on-k8s

[tcdowney]

I haven't had a chance to look at the change itself too deeply yet (plan on doing so later today), but wanted to share some context around the original design here.

#102

The Valid/Invalid status conditions were added to make this easier to debug by human users which is why you wouldn't see any code references or anything checking them. We found that in live environments that users may have permissions to view a CFRoute, but not resources from the underlying ingress implementation (e.g. Contour HTTPProxy) so we wanted to surface errors up to a place that they could actually see.

I think it is fine to consolidate this type of information under the Ready conditions, but want to make sure we're still able to provide that same information to the user somewhere.

cc @davewalter who wrote that original issue

[danail-branekov]

The motivation of replacing Valid/Invalid conditions on routes with Ready is that being valid is actually true/false/unknown. This fits quite well into a single condition with its three states - True/False/Uknown. Having two conditions brings 9 states alltogether, 6 of them simply not making sense.

I kind of feel that the name of the condition - Ready - might not have the semantics of Valid (like in being correct) but correctness should be guaranteed by validators. When a route is valid and usable, then this is what Ready stands for. If it is unusable, then it is not ready and the condition message and reason should provide details on what the issue is.

As per ergonomics - whether users are looking into a single condition, or two - I don't think it matters so much. A single condition just makes the code simpler.

[davewalter]

The changes look good. We tried to model the status after the way Contour reports the status of its resources but I understand that this is non-standard and could make it harder to implement an alternative routing layer on top of something like Istio. The original vision was to bubble the real-time status from the underlying resources up to the CFRoute's status for visibility, but this was never implemented.

The merge-base changed after approval.