(e2e-fix) do not check for updated csv that is likely to be GC'd

In the test `Operator Group cleanup csvs with bad namespace annotation`, the polling
logic that updates a copied csv with a bad annotation was checking to see if the
update was successful. However, once the copied csv is given a bad annotation, the CSV
is GC'd, and if the collection happens immediately, the polling logic fails. This fix
removes the logic that attempts to check the updated CSV, and instead relies on the
updateErr being nil to assert that the update was successful.

Signed-off-by: Anik Bhattacharjee <anikbhattacharya93@gmail.com>

test/e2e/operator_groups_e2e_test.go

@@ -2021,16 +2021,10 @@ var _ = Describe("Operator Group", func() {
  fetchedCSV.Annotations[v1.OperatorGroupNamespaceAnnotationKey] = fetchedCSV.GetNamespace()
  _, updateErr := crc.OperatorsV1alpha1().ClusterServiceVersions(otherNamespaceName).Update(context.TODO(), fetchedCSV, metav1.UpdateOptions{})
  if updateErr != nil {
+ GinkgoT().Logf("Error updating copied CSV (in %v): %v", otherNamespaceName, updateErr.Error())
  return false, updateErr
  }
- updatedCSV, updatedfetchErr := crc.OperatorsV1alpha1().ClusterServiceVersions(otherNamespaceName).Get(context.TODO(), csvName, metav1.GetOptions{})
- if updatedfetchErr != nil {
- return false, updatedfetchErr
- }
- if updatedCSV.Annotations[v1.OperatorGroupNamespaceAnnotationKey] == fetchedCSV.GetNamespace() {
- return true, nil
- }
- return false, nil
+ return true, nil
  })
  require.NoError(GinkgoT(), err)
  GinkgoT().Log("Done updating copied CSV with bad annotation OperatorGroup, waiting for CSV to be gc'd")