enhancements/update/targeted-update-edge-blocking: Drop Evaluating

Following up on 6af8d09
(enhancements/update/targeted-update-edge-blocking: Update after API
landed, 2021-09-20, #910), with more changes to align this enhancement
with the actual implementation.

We never implemented Evaluating, because Recommended=Unknown means
we're trying (and failing) to figure out if some of the target's risks
apply to the cluster.

And:

  // +kubebuilder:validation:Required
  // +kubebuilder:validation:MinItems=1
  // +listType=atomic
  // +required
  MatchingRules []ClusterCondition `json:"matchingRules"`

means that empty matchingRules is not possible, as previously discussed around:

  Mitigating that "where did that edge go?" confusion in the
  required-property alternative, David expects graph-admins to be
  keeping watch over enough ClusterVersion content...

in the alternatives section of the enhancement.

Author: wking

enhancements/update/targeted-update-edge-blocking.md

@@ -198,7 +198,6 @@ type ConditionalUpdate struct {
 
 	// conditions represents the observations of the conditional update's
 	// current status. Known types are:
-	// * Evaluating, for whether the cluster-version operator will attempt to evaluate any risks[].matchingRules.
 	// * Recommended, for whether the update is recommended for the current cluster.
 	// +patchMergeKey=type
 	// +patchStrategy=merge
@@ -314,12 +313,10 @@ Including edges which are recommended for no clusters under `conditionalEdges` g
 ### Cluster-version operator support for the enhanced schema
 
 The cluster-version operator will learn to parse [`conditionalEdges`](#enhanced-cincinnati-json-representation) into [`conditionalUpdates`](#enhanced-clusterversion-representation).
-For `conditionalUpdates` entries where each `risks` entry contains at least one recognized `matchingRules` entry, the operator will set the `Evaluating` condition to `True`.
-Otherwise the `Evaluating` condition will be set to `False`, and the `Recommended` condition can be immediately set to `False` (if there are no `matchingRules` entries at all) or `Unknown` (if there are unrecognized `matchingRules` entries).
-`edges` will continue to go straight into `availableUpdates`.
+The `Recommended` condition can be immediately set to `Unknown` until the `matchingRules` for all the update's risks have been evaluated.
 The operator will log an error if the same target is included in both `edges` and `conditionalEdges`, but will prefer the `conditionalEdges` entry in that case.
 
-Additionally, the operator will continually re-evaluate the blocking conditionals in `conditionalUpdates` and update `conditionalUpdates[].risks` accordingly.
+Additionally, the operator will continually re-evaluate the blocking conditionals in `conditionalUpdates` and update `conditionalUpdates[].conditions` accordingly.
 The timing of the evaluation and freshness are largely internal details, but to avoid [consuming excessive monitoring resources](#malicious-conditions) and because [the rules should be based on slowly-changing state](#clusters-moving-into-the-vulnerable-state-after-updating), the operator will handle polling with the following restrictions:
 
 * The cluster-version operator will cache polling results for each query, so a single query which is used in evaluating multiple risks over multiple conditional update targets will only be evaluated once per round.
@@ -535,10 +532,6 @@ status:
             or
             0 * cluster_infrastructure_provider
     conditions:
-    - lastTransitionTime: 2021-08-28T01:00:00Z
-      type: Evaluating
-      status: True
-      reason: Periodically evaluating risks associated with this update.
     - lastTransitionTime: 2021-08-28T01:05:00Z
       type: Recommended
       status: False