Until we can remove that namespace.  Some background in [1].  We
cannot remove the namespace until we land [2].

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1875900
[2]: openshift/cluster-version-operator#438

…=False

Because:

  Upgradeable=False

    Reason: MultipleReasons
    Message: Cluster cannot be upgraded between minor versions for multiple reasons: AdminAckRequired,IncompatibleOperatorsInstalled

doesn't include all the useful information needed to resolve those
issues.  This pivots to using the same approach we use today when
aggregating multiple Upgradeable=False ClusterOperators.

Also shift the patch-blocking overrides check in front of the other
minor blocking checks.  It's more important (because it blocks more
targets), and it also will not included a nested sub-list (which might
be confusing, because today I'm not adding indents or any such markers
to make it easy to distinguish levels in a nested list hierarchy).

This cherry-picks 0c742e5 (pkg/cvo/upgradeable: Include messages
for multiple-reason Upgradeable=False, 2021-10-07, openshift#671) back to 4.8,
with a minor context change because 4.8 doesn't have 0afb8a8 (Add a
manifest annotation to be used for object deletion, 2020-08-17, openshift#438).

…=False

Because:

  Upgradeable=False

    Reason: MultipleReasons
    Message: Cluster cannot be upgraded between minor versions for multiple reasons: AdminAckRequired,IncompatibleOperatorsInstalled

doesn't include all the useful information needed to resolve those
issues.  This pivots to using the same approach we use today when
aggregating multiple Upgradeable=False ClusterOperators.

Also shift the patch-blocking overrides check in front of the other
minor blocking checks.  It's more important (because it blocks more
targets), and it also will not included a nested sub-list (which might
be confusing, because today I'm not adding indents or any such markers
to make it easy to distinguish levels in a nested list hierarchy).

This cherry-picks 0c742e5 (pkg/cvo/upgradeable: Include messages
for multiple-reason Upgradeable=False, 2021-10-07, openshift#671) back to 4.8,
with a minor context change because 4.8 doesn't have 0afb8a8 (Add a
manifest annotation to be used for object deletion, 2020-08-17, openshift#438).

I'd accidentally broken this in e8ffccb (lib: Add autogeneration
for some resource* functionality, 2020-07-29, openshift#420), when I moved the
health checks out of the Do methods and began passing typedObject into
them.  typedObject is the release manifest, which lacks the status
attributes we want the health checks to cover.

This also catches the generation script up with some past manual
changes:

* 0afb8a8 (Add a manifest annotation to be used for object
  deletion, 2020-08-17, openshift#438).
* 05e1af7 (Log resource diffs on update only in reconcile mode,
  2021-07-13, openshift#628).

The always-fatal ApplyAPIServicev1 function gives us the required
symmetry with 0afb8a8's DeleteAPIServicev1, although I'm a bit
fuzzy on who would have been using an APIService manifest.  I'm not
excited about supporting a new manifest kind I know nothing about, and
failing all attempts at non-delete reconciling should protect us from
accidentally encouraging manifest authors to feed us this kind.

I'd accidentally broken this in e8ffccb (lib: Add autogeneration
for some resource* functionality, 2020-07-29, openshift#420), when I moved the
health checks out of the Do methods and began passing typedObject into
them.  typedObject is the release manifest, which lacks the status
attributes we want the health checks to cover.

This also catches the generation script up with some past manual
changes:

* 0afb8a8 (Add a manifest annotation to be used for object
  deletion, 2020-08-17, openshift#438).
* 05e1af7 (Log resource diffs on update only in reconcile mode,
  2021-07-13, openshift#628).

The always-fatal ApplyAPIServicev1 function gives us the required
symmetry with 0afb8a8's DeleteAPIServicev1, although I'm a bit
fuzzy on who would have been using an APIService manifest.  I'm not
excited about supporting a new manifest kind I know nothing about, and
failing all attempts at non-delete reconciling should protect us from
accidentally encouraging manifest authors to feed us this kind.

I'd accidentally broken this in e8ffccb (lib: Add autogeneration
for some resource* functionality, 2020-07-29, openshift#420), when I moved the
health checks out of the Do methods and began passing typedObject into
them.  typedObject is the release manifest, which lacks the status
attributes we want the health checks to cover.

This also catches the generation script up with some past manual
changes:

* 0afb8a8 (Add a manifest annotation to be used for object
  deletion, 2020-08-17, openshift#438).
* 05e1af7 (Log resource diffs on update only in reconcile mode,
  2021-07-13, openshift#628).

The always-fatal ApplyAPIServicev1 function gives us the required
symmetry with 0afb8a8's DeleteAPIServicev1, although I'm a bit
fuzzy on who would have been using an APIService manifest.  I'm not
excited about supporting a new manifest kind I know nothing about, and
failing all attempts at non-delete reconciling should protect us from
accidentally encouraging manifest authors to feed us this kind.

The original APIService reconciliation landed in 662e182 (handle
APIService, Service objects, 2018-09-27, openshift#26).  We definitely
reconcile a bunch of Service manifests (e.g. for serving operator
metrics, including the CVO's own Service), but it's not clear what the
use case was for APIService.

DeleteAPIServicev1 landed in 0afb8a8 (Add a manifest annotation to
be used for object deletion, 2020-08-17, openshift#438), but was never
consumed.  We dropped APIService reconciliation support in 5681a70
(Drop APIService support, 2021-06-10, openshift#566).  This commit drops the
unused DeleteAPIServicev1.  Auditing z-stream tips from 4.3 through
4.11:

  $ oc adm release extract --to 4.11 quay.io/openshift-release-dev/ocp-release-nightly@sha256:080e5cf5e3e043ac0877b8f545ba2b596016f3fd76f3f457d15060603b3615e1
  $ oc adm release extract --to 4.10 quay.io/openshift-release-dev/ocp-release:4.10.13-x86_64
  $ oc adm release extract --to 4.9 quay.io/openshift-release-dev/ocp-release:4.9.32-x86_64
  $ oc adm release extract --to 4.8 quay.io/openshift-release-dev/ocp-release:4.8.39-x86_64
  $ oc adm release extract --to 4.7 quay.io/openshift-release-dev/ocp-release:4.7.50-x86_64
  $ oc adm release extract --to 4.6 quay.io/openshift-release-dev/ocp-release:4.6.57-x86_64
  $ oc adm release extract --to 4.5 quay.io/openshift-release-dev/ocp-release:4.5.41-x86_64
  $ oc adm release extract --to 4.4 quay.io/openshift-release-dev/ocp-release:4.4.33-x86_64
  $ oc adm release extract --to 4.3 quay.io/openshift-release-dev/ocp-release:4.3.40-x86_64
  $ grep -r 'kind: APIService' 4.*
  ...no hits...

I'd accidentally broken this in e8ffccb (lib: Add autogeneration
for some resource* functionality, 2020-07-29, openshift#420), when I moved the
health checks out of the Do methods and began passing typedObject into
them.  typedObject is the release manifest, which lacks the status
attributes we want the health checks to cover.

This also catches the generation script up with some past manual
changes:

* 0afb8a8 (Add a manifest annotation to be used for object
  deletion, 2020-08-17, openshift#438).
* 05e1af7 (Log resource diffs on update only in reconcile mode,
  2021-07-13, openshift#628).