During the cluster upgrade process there could be some prerequisites (version gates) users need to follow before being able to schedule the upgrade.

In order to display prerequisites, we are currently fetching all existing version gates and we are filtering them based on cluster versions (from > to) and other properties.

This logic is located inside UpgradeAcknowledgeHelpers.js, specifically here:
https://github.com/RedHatInsights/uhc-portal/blob/db4db260633a91d5e2a2dff2868aec98b8e9d77f/src/components/clusters/common/Upgrades/UpgradeAcknowledge/UpgradeAcknowledgeHelpers.js#L24

(in function getClusterAcks())

We can remove all this client side logic and ask the APIs if there are missing acknowledgements. This is safer as it ensures clients and APIs are always in sync in the future. 

We can call the endpoint to schedule the upgrade (POST clusters/{cluster_id}/upgrade_policies) with the dryRun query param set to true. If a 200 is returned, there are no missing version gates. A 400 return value will have the list of version gates which an agreement is still needed.

See OCMUI-3064 comments for more context

This is a good move to push UI client side business logic to the backend API which has more knowledge of what to check for and can change over time.

Acceptance Criteria

• Replace client side code which gets 'some' version gates and filters out those who need acknowledgement, which we display in upgrade prerequisites. 
• Switch to new API which returns a list of version gates which require acknowledgment
• Update client side to accept results of new API call. 

Concerns that have arisen and should be considered

During mock testing, an edge case was found that at this point has not been an issue but I want to explain it here.

When you run the upgrade policy API with the DryRun=true flag, it runs the operation exactly as it would in a real situation, but it does not store the value to the back end tables.  This said, the first check that the upgrade policy POST operation does is to see if a upgrade policy is already in existence.  If there is a policy, the dryRun=true results immediately error back with "policy already exist" and does not check version gates for that specific upgrade.

Edge Case:

     As a user, I set a manual update for one month (Day 30) from today (day 1) and I approve any gates that might be at issue. These gates are only for minor updates 4.y >  4.(y+1).  On day 2, a new gate is created to go to version 4.(y+1).  If the UI tries to run the dryRun=true code at this point, an error will be returned saying a manual policy is already in place and will not say anything about a new version gate. 

Therefore, I opened a ticket for the back end OCM team OCM-17206.  I asked the dryRun be allowed to run without throwing an error if a policy already exist, but this was against their design.  The ticket then asks if we can create another API to test the gates specifically.  The is an ongoing discussion that has no resolution currently.

Path Forward:

As this is an edge case of my own creation and version gates have always been created before the next minor release is available as an upgrade choice, I am choosing to disregard this remote possibility in the current solution. If a new API is created by the back end, we may want to revisit this.  That said, from the UI perspective, if an unmet version gate does get by, the upgrade will error and the user will be able to see that in the logs.  At that point, they can correct the unmet issues and resubmit the upgrade policy.