Problem:
If an operator is being upgraded that provides a required API whose GVK
has not changed since the previous version of the operator and
uses a skipRange instead of the Spec.Replaces field, OLM will:
* Add the new operator to the generation, and marking the APIs it
    provides as "present".
* Remove the old operator from the generation, marking the APIs it
    provides as "absent", despite being provided by the new version of the
    operator.
* Attempt to resolve the "missing" APIs, overwriting the new version
    of the operator with a copy that  does not have its Spec.Replaces field
    set.

This causes OLM to fail the upgrade, where the old operator's CSV will
not be replaced and the new operators CSV will run into an intercepting
API Provider issue.

Solution:
Update OLM to remove the old operator from the current generation before
adding the new operator to the generation.

Problem:
In an upgrade where v1 of Operator A provides an API and v1 of Operator
B depends on the API, where the ownership of the API is transferred from
Operator A to Operator B during the upgrade, OLM may run into a
situation where Operator B is updated first. This causes OLM to fail to
calculate the generation because multiple operator provide the same
API.

Solution:
Add and remove updates as a set to prevent the situation described
above.