Impact CNO must use reconciliation controller in order to support dual stack in 4.12

We're asking the following questions to evaluate whether or not OCPBUGS-13067 warrants changing update recommendations from either the previous X.Y or X.Y.Z. The ultimate goal is to avoid recommending an update which introduces new risk or reduces cluster functionality in any way. In the absence of a declared update risk (the status quo), there is some risk that the existing fleet updates into the at-risk releases. Depending on the bug and estimated risk, leaving the update risk undeclared may be acceptable.

Which 4.y.z to 4.y'.z' updates increase vulnerability?

Customers upgrading to  any 4.12.18

Which types of clusters?

Any clusters where customers have populated the "additionalNetworks" field in the CNO "networks" object with a "rawCNIConfig"  that reference `"type": "whereabouts"

What is the impact? Is it serious enough to warrant removing update recommendations?

The upgrade will stall (indefinitely) and require manual intervention to proceed.

How involved is remediation?

Requires manual intervention by users to apply a work-around that causes them to "opt out" of the reconciliation process

Remediation procedure in https://gist.github.com/dougbtv/015ce004967421019cbabe6df60217a2

Notably: The customer should also probably manually start the reconciler, however, we have not yet provided these steps at the time of writing (6/8/23)

Is this a regression?

Yes, in 4.12.18+ until patch is in z-stream from https://issues.redhat.com/browse/OCPBUGS-13067