Protecting us from [1,2]:

  converting (v1beta1.Role) to (v1.Role): unknown conversion

in unit tests.  The manual conversion and wash through JSON seems like
a terrible hack, but I haven't been able to figure out a more elegant
approach yet.  From [3]:

  Promotes the rbac.authorization.k8s.io/v1beta1 API to v1 with no changes

so all we really need is the apiVersion bump.

[1]: kubernetes/kubernetes#90018
[2]: openshift#420 (comment)
[3]: kubernetes/kubernetes#49642

Protecting us from [1,2]:

  converting (v1beta1.Role) to (v1.Role): unknown conversion

in unit tests.  The manual conversion and wash through JSON seems like
a terrible hack, but I haven't been able to figure out a more elegant
approach yet.  From [3]:

  Promotes the rbac.authorization.k8s.io/v1beta1 API to v1 with no changes

so all we really need is the apiVersion bump.

[1]: kubernetes/kubernetes#90018
[2]: openshift#420 (comment)
[3]: kubernetes/kubernetes#49642

Protecting us from [1,2]:

  converting (v1beta1.Role) to (v1.Role): unknown conversion

in unit tests.  The manual conversion and wash through JSON seems like
a terrible hack, but I haven't been able to figure out a more elegant
approach yet.  From [3]:

  Promotes the rbac.authorization.k8s.io/v1beta1 API to v1 with no changes

so all we really need is the apiVersion bump.

Also add similar logic for apiregistration, since that's the other
group where we register multiple schema versions.

[1]: kubernetes/kubernetes#90018
[2]: openshift#420 (comment)
[3]: kubernetes/kubernetes#49642

Protecting us from [1,2]:

  converting (v1beta1.Role) to (v1.Role): unknown conversion

Because merging and application are also version-dependent, it's hard
to paper over this in resourceread with automatic type conversion.
Although from [3]:

  Promotes the rbac.authorization.k8s.io/v1beta1 API to v1 with no changes

so all we really need is the apiVersion bump.  Anyhow, with this
commit, I'm doubling down on the approach from 4ee7b07 (Add
apiextensions.k8s.io/v1 support for CRDs, 2019-10-22, openshift#259) and
collapsing the readers into two helpers that support all of our types
and return runtime.Object.

From 0a255ab (cvo: Use protobuf for sending events and other basic
API commands, 2019-01-18, openshift#90), protobuf is more efficient, so we
should use it where possible.

And because all of this is very tedious to maintain by hand, there's
now a Python generator to spit out all the boilerplate.

[1]: kubernetes/kubernetes#90018
[2]: openshift#420 (comment)
[3]: kubernetes/kubernetes#49642

When we moved to 0.19 Kube tooling in ef236c3 (vendor: Bump
client-go and library-go to current 4.6 tips 2020-07-24, openshift#420), the
tooling moved to klog v2.  Port our local klog consumers so we don't
have to worry about configuring multiple klogs [1].

Generated with:

  $ sed -i 's|^go 1.13|go 1.15|' go.mod
  $ sed -i 's|k8s.io/klog v1.0.0|k8s.io/klog/v2 v2.3.0|' go.mod
  $ sed -i 's|"k8s.io/klog"|"k8s.io/klog/v2"|' $(git grep -l k8s.io/klog cmd lib pkg)
  $ sed -i 's/klog.V(\([0-9]\)) /klog.V(\1).Enabled() /' $(git grep -l klog.V cmd lib pkg)
  $ go mod tidy
  $ go mod vendor
  $ git add -A go.* vendor

using:

  $ go version
  go version go1.15.2 linux/amd64

The change to Go 1.15 catches us up with 1d9a319 (Dockerfile.rhel:
Bump to Go 1.15, 2020-09-16, openshift#457).

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1883705

When we moved to 0.19 Kube tooling in ef236c3 (vendor: Bump
client-go and library-go to current 4.6 tips 2020-07-24, openshift#420), the
tooling moved to klog v2.  Port our local klog consumers so we don't
have to worry about configuring multiple klogs [1].

Generated with:

  $ sed -i 's|^go 1.13|go 1.15|' go.mod
  $ sed -i 's|k8s.io/klog v1.0.0|k8s.io/klog/v2 v2.3.0|' go.mod
  $ sed -i 's|"k8s.io/klog"|"k8s.io/klog/v2"|' $(git grep -l k8s.io/klog cmd lib pkg)
  $ sed -i 's|klog.V(\([0-9]\)) |klog.V(\1).Enabled() |' $(git grep -l klog.V cmd lib pkg)
  $ go mod tidy
  $ go mod vendor
  $ git add -A go.* vendor

using:

  $ go version
  go version go1.15.2 linux/amd64

The change to Go 1.15 catches us up with 1d9a319 (Dockerfile.rhel:
Bump to Go 1.15, 2020-09-16, openshift#457).

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1883705

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 dropped this in cc9292a (lib/resourcebuilder: Replace wait-for
with single-shot "is it alive now?", 2020-07-30, openshift#400), claiming:

  There's no object status for CRDs or DaemonSets that marks "we are
  really hurting".  The v1.18.0 Kubernetes CRD and DaemonSet
  controllers do not set any conditions in their operand status
  (although the API for those conditions exists [2,3]).  With this
  commit, we have very minimal wait logic for either.  Sufficiently
  unhealthy DaemonSet should be reported on via their associated
  ClusterOperator, and sufficiently unhealthy CRD should be reported
  on when we fail to push any custom resources consuming them
  (Task.Run retries will give the API server time to ready itself
  after accepting a CRD update before the CVO fails its sync cycle).

But from [1]:

  > It might take a few seconds for the endpoint to be created. You
  > can watch the Established condition of your
  > CustomResourceDefinition to be true or watch the discovery
  > information of the API server for your resource to show up.

So I was correct that we will hear about CRD issues when we fail to
push a dependent custom resource.  But I was not correct in claiming
that the CRD controller set no conditions.  I was probably confused by
e8ffccb (lib: Add autogeneration for some resource* functionality,
2020-07-29, openshift#420), which broke the health-check inputs as described in
002591d (lib/resourcebuilder: Use actual resource in check*Health
calls, 2022-05-03, openshift#771).  The code I removed in cc9292a was in
fact looking at the Established condition already.

This commit restores the Established check, but without the previous
PollImmediateUntil wait.

[1]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

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 dropped this in cc9292a (lib/resourcebuilder: Replace wait-for
with single-shot "is it alive now?", 2020-07-30, openshift#400), claiming:

  There's no object status for CRDs or DaemonSets that marks "we are
  really hurting".  The v1.18.0 Kubernetes CRD and DaemonSet
  controllers do not set any conditions in their operand status
  (although the API for those conditions exists [2,3]).  With this
  commit, we have very minimal wait logic for either.  Sufficiently
  unhealthy DaemonSet should be reported on via their associated
  ClusterOperator, and sufficiently unhealthy CRD should be reported
  on when we fail to push any custom resources consuming them
  (Task.Run retries will give the API server time to ready itself
  after accepting a CRD update before the CVO fails its sync cycle).

But from [1]:

  > It might take a few seconds for the endpoint to be created. You
  > can watch the Established condition of your
  > CustomResourceDefinition to be true or watch the discovery
  > information of the API server for your resource to show up.

So I was correct that we will hear about CRD issues when we fail to
push a dependent custom resource.  But I was not correct in claiming
that the CRD controller set no conditions.  I was probably confused by
e8ffccb (lib: Add autogeneration for some resource* functionality,
2020-07-29, openshift#420), which broke the health-check inputs as described in
002591d (lib/resourcebuilder: Use actual resource in check*Health
calls, 2022-05-03, openshift#771).  The code I removed in cc9292a was in
fact looking at the Established condition already.

This commit restores the Established check, but without the previous
PollImmediateUntil wait.

[1]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

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 dropped this in cc9292a (lib/resourcebuilder: Replace wait-for
with single-shot "is it alive now?", 2020-07-30, openshift#400), claiming:

  There's no object status for CRDs or DaemonSets that marks "we are
  really hurting".  The v1.18.0 Kubernetes CRD and DaemonSet
  controllers do not set any conditions in their operand status
  (although the API for those conditions exists [2,3]).  With this
  commit, we have very minimal wait logic for either.  Sufficiently
  unhealthy DaemonSet should be reported on via their associated
  ClusterOperator, and sufficiently unhealthy CRD should be reported
  on when we fail to push any custom resources consuming them
  (Task.Run retries will give the API server time to ready itself
  after accepting a CRD update before the CVO fails its sync cycle).

But from [1]:

  > It might take a few seconds for the endpoint to be created. You
  > can watch the Established condition of your
  > CustomResourceDefinition to be true or watch the discovery
  > information of the API server for your resource to show up.

So I was correct that we will hear about CRD issues when we fail to
push a dependent custom resource.  But I was not correct in claiming
that the CRD controller set no conditions.  I was probably confused by
e8ffccb (lib: Add autogeneration for some resource* functionality,
2020-07-29, openshift#420), which broke the health-check inputs as described in
002591d (lib/resourcebuilder: Use actual resource in check*Health
calls, 2022-05-03, openshift#771).  The code I removed in cc9292a was in
fact looking at the Established condition already.

This commit restores the Established check, but without the previous
PollImmediateUntil wait.

[1]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition

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).

I'd dropped this in cc9292a (lib/resourcebuilder: Replace wait-for
with single-shot "is it alive now?", 2020-07-30, openshift#400), claiming:

  There's no object status for CRDs or DaemonSets that marks "we are
  really hurting".  The v1.18.0 Kubernetes CRD and DaemonSet
  controllers do not set any conditions in their operand status
  (although the API for those conditions exists [2,3]).  With this
  commit, we have very minimal wait logic for either.  Sufficiently
  unhealthy DaemonSet should be reported on via their associated
  ClusterOperator, and sufficiently unhealthy CRD should be reported
  on when we fail to push any custom resources consuming them
  (Task.Run retries will give the API server time to ready itself
  after accepting a CRD update before the CVO fails its sync cycle).

But from [1]:

  > It might take a few seconds for the endpoint to be created. You
  > can watch the Established condition of your
  > CustomResourceDefinition to be true or watch the discovery
  > information of the API server for your resource to show up.

So I was correct that we will hear about CRD issues when we fail to
push a dependent custom resource.  But I was not correct in claiming
that the CRD controller set no conditions.  I was probably confused by
e8ffccb (lib: Add autogeneration for some resource* functionality,
2020-07-29, openshift#420), which broke the health-check inputs as described in
002591d (lib/resourcebuilder: Use actual resource in check*Health
calls, 2022-05-03, openshift#771).  The code I removed in cc9292a was in
fact looking at the Established condition already.

This commit restores the Established check, but without the previous
PollImmediateUntil wait.

[1]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customresourcedefinition