Description of problem:
Currently we rely on a ClusterVersion policy to determine whether a spoke cluster is upgraded(comppliant) or not. But ClusterVersion CR itself does not have a field for existing cluster version (except searching for latest Completed version/image in history field), we are setting the "desiredUpdate" spec to determine compliance, and this doesn't work in various scenarios: 
1. after fresh deployment, desiredUpdate is always null, meaning the policy will always be NonCompliant even if we set desiredUpdate to existing cluster version.
2. this policy compliance only indidates whether the CR is patched or not, it could be patched but cannot be upgraded for many reasons (e.g., non-existed version number, unsigned image.. etc), but in this case, even if cluster is NOT upgraded to desired version, the policy will be Compliant. 
3. Even if in an ideal scenario, where the policy got applied successfully, the policy will become compliant right after the ClusterVersion CR is updated, meaning cluster upgrade has just started (as opposed to completed).

Version-Release number of selected component (if applicable):
4.10

How reproducible:
100%

Steps to Reproduce:
1. trying to start platform upgrade using this policy (https://gitlab.cee.redhat.com/ran/lab-ztp/-/commit/aa0d7be5d2f3e7059391a66bee09712dd4c07b7d) from following source-cr: https://github.com/openshift-kni/cnf-features-deploy/blob/master/ztp/source-crs/ClusterVersion.yaml

Actual results:
- candidate clusters and upgrade status/results cannot be properly determined

Expected results:
- this policy should correctly indicate whether cluster's existing version matches with desired version

 
Additional info: