switch the deployer pod to use apply client to avoid conflicts

cae0b5e (React to degraded condition change, 2019-04-23,
openshift/origin#22644) moved this code from Failing to Degraded,
likely inspired by [1].  But Degraded is only used in ClusterOperator.
ClusterVersion kept using Failing, as seen in [2].  This commit
returns us to watching for Failing (the condition the CVO has been
setting the whole time), and informing the caller for any non-happy
statuses (or the lack of a Failing condition at all).

Even though the issue causing `Failing=True` may block the current
update from progressing, it should not block admins from requesting a
new update target.  For some bugs, retargeting is the recommended way
to resolve the issue that is currently sticking the update [3].

[1]: openshift/api#287
[2]: openshift/cluster-version-operator#191
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1988576#c30

OCPBUGS-3714: pkg/cli/admin/upgrade: Report on Failing!=False conditions

The outgoing wording dates back to the initial subcommand
implementation in openshift/origin@65cce8c37d (Add `oc adm upgrade` to
display available updates or trigger an update, 2018-12-04,
openshift/origin#21605).  But "force" is easy to conflate with the
--force option, and we occasionally hear of users who set --force
under the mistaken impression that it is related to the
recommended-ness of the target release image.

This message is only rendered when availableUpdates is empty, so
--to-image is unlikely to be sufficient.  The current output will be:

  $ oc adm upgrade --to-image quay.io/openshift-release-dev/ocp-release@sha256:20e270c3349fe2fcb38fd0da155329babc02d6b53e7e06ff235346c3c1cf11b5
  error: no recommended updates, specify --allow-explicit-upgrade to continue with the update or wait for new updates to be available.

which we could stiffen up by including some of --help's current
warnings about --allow-explicit-upgrade risk, but we can address that
in follow-up work.

…quire-force

pkg/cli/admin/upgrade: Drop "force" from "No updates available"

Comparing release text for various arch-specific shards of the
multi-arch 4.12.0-rc.0 release:

  $ for B in arm64 ppc64le s390x; do diff -u <(curl -s https://mirror.openshift.com/pub/openshift-v4/multi/clients/ocp/4.12.0-rc.0/amd64/release.txt) <(curl -s "https://mirror.openshift.com/pub/openshift-v4/multi/clients/ocp/4.12.0-rc.0/${B}/release.txt"); done
  --- /dev/fd/63  2022-11-16 14:57:24.849975880 -0800
  +++ /dev/fd/62  2022-11-16 14:57:24.854975880 -0800
  @@ -13,7 +13,7 @@
   Name:           4.12.0-rc.0
   Digest:         sha256:7ac78aaca993bf307010e8e92642da2bc28e275fbac241b42f24be46153f12d1
   Created:        2022-11-10T19:12:09Z
  -OS/Arch:        linux/amd64
  +OS/Arch:        linux/arm64
   Manifests:      643
   Metadata files: 1

  --- /dev/fd/63  2022-11-16 14:57:26.195975808 -0800
  +++ /dev/fd/62  2022-11-16 14:57:26.195975808 -0800
  @@ -13,7 +13,7 @@
   Name:           4.12.0-rc.0
   Digest:         sha256:7ac78aaca993bf307010e8e92642da2bc28e275fbac241b42f24be46153f12d1
   Created:        2022-11-10T19:12:09Z
  -OS/Arch:        linux/amd64
  +OS/Arch:        linux/ppc64le
   Manifests:      643
   Metadata files: 1

  --- /dev/fd/63  2022-11-16 14:57:26.821975774 -0800
  +++ /dev/fd/62  2022-11-16 14:57:26.824975774 -0800
  @@ -13,7 +13,7 @@
   Name:           4.12.0-rc.0
   Digest:         sha256:7ac78aaca993bf307010e8e92642da2bc28e275fbac241b42f24be46153f12d1
   Created:        2022-11-10T19:12:09Z
  -OS/Arch:        linux/amd64
  +OS/Arch:        linux/s390x
   Manifests:      643
   Metadata files: 1

With this change, those OS/Arch properties will be rendered like:

  OS/Arch:        multi (linux/amd64)

and similar, to make it more obvious that the release payload as a
whole is multi-architecture.

pkg/cli/admin/release/info: Render multi-arch release information

OCPBUGS-4280: oc import-image: reflect import image error

Reconciling with https://github.com/openshift/ocp-build-data/tree/61541c1c730569d20db98c885bb07d7ee96e648c/images/openshift-enterprise-cli.yml

Align OCP versions with the new CI registry

Currently, user can extract tools in specific operating systems
by setting `--command-os`. However, there is no way for user extracting
specific architectures in these operating systems.

This PR adds an ability to `--command-os` flag to also specify architecture
like `linux/arm64`, `mac/arm64`. Users are already used to use this syntax
from `filter-by-os` flag and this can also be used for `--command-os` flag.

…-4.13-openshift-enterprise-cli

Updating openshift-enterprise-cli images to be consistent with ART

OCPBUGS-3526: Proceed archive if Lsetxattr gets unsupported error

Rename registry.svc.ci.openshift.org to registry.ci.openshift.org

Steps:

$ go get github.com/openshift/api@a671aa8
$ go mod tidy
$ go mod vendor

OCPBUGS-4517: oc adm release: Support extracting commands in specified architectures

Reconciling with https://github.com/openshift/ocp-build-data/tree/ce241462943e940cd71984f7984819c7a551f5e1/images/openshift-enterprise-deployer.yml

Handle non-amd64 command pulls from amd64 payload

If the image to describe contains image manifests, this adds both os/arch
and digest of each manifest to the output.

…-4.13-openshift-enterprise-deployer

Updating openshift-enterprise-deployer images to be consistent with ART

IR-266: Add image manifests to 'describe image'

FDN-112: Parse any jira reference from commit text, not just OCPBUGS

OTA-818: pkg/cli/admin/upgrade: Support --to-multi-arch per OTA-818