1. Proposed title of this feature request

Enhance the --force argument during OCP upgrades to prevent an inconsistent state.

2. What is the nature and description of the request?

When trying to upgrade a cluster by command line the argument --force might let the cluster in an inconsistent state as all the guards implemented. In this sense, the request is to enhance the argument with a confirmation message if the path is not supported like the downgrade

Currently the command is applied without confirmation, for instance in the following wrong command is applying a downgrade from 4.14.12 to 4.13.28 that is not supported and irrevocable:

$ oc adm upgrade --allow-upgrade-with-warnings --allow-explicit-upgrade --force --to-image=quay.io/openshift-release-dev/ocp-release@sha256:1c834045db967d579aa2f1ef6f836dcb21db13d804bdffb972e8f4a7a4d59fc2
warning: The requested upgrade image is not one of the available updates. You have used --allow-explicit-upgrade for the update to proceed anyway
warning: --force overrides cluster verification of your supplied release image and waives any update precondition failures.
Requested update to release image quay.io/openshift-release-dev/ocp-release@sha256:1c834045db967d579aa2f1ef6f836dcb21db13d804bdffb972e8f4a7a4d59fc2

$ oc get clusterversion
NAME   VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.12   True     True       80s  Working towards 4.13.28: 4 of 841 done (0% complete)

If it could be possible to identify the version based on the image digest to clarify at the warning message  that this is a downgrade or upgrade, that is not supported and can potentially let the cluster inconsistent and add a prompt to confirm the operation in order to avoid mistakes 

This mainly happens in disconnected environments, it's known that --force argument is discouraged to use but it's an option and customers are using it regardless of the warning message at the documentation.

3. Why does the customer need this? (List the business requirements here)

The customer manages a large fleet of clusters, and while the upgrade process is well-documented, human errors still occur

4. List any affected packages or components.

Upgrade