Handle finalizers (creation and deletion) better

[anik120]

Deleting the finalizer and updating the status (introduced in #379) in the same reconciliation loop is never actually executed in the same reconciliation loop because of the way Reconcile is setup.

// Update the status subresource before updating the main object. This is
// necessary because, in many cases, the main object update will remove the
// finalizer, which will cause the core Kubernetes deletion logic to
// complete. Therefore, we need to make the status update prior to the main
// object update to ensure that the status update can be processed before
// a potential deletion.
if !equality.Semantic.DeepEqual(existingCatsrc.Status, reconciledCatsrc.Status) {
        if updateErr := r.Client.Status().Update(ctx, reconciledCatsrc); updateErr != nil {
	        return res, apimacherrors.NewAggregate([]error{reconcileErr, updateErr})
        }
}
existingCatsrc.Status, reconciledCatsrc.Status = v1alpha1.ClusterCatalogStatus{}, v1alpha1.ClusterCatalogStatus{}
if !equality.Semantic.DeepEqual(existingCatsrc, reconciledCatsrc) {
        if updateErr := r.Client.Update(ctx, reconciledCatsrc); updateErr != nil {
	        return res, apimacherrors.NewAggregate([]error{reconcileErr, updateErr})
        }
}

When the status and the main body (eg metadata.finalizer) is updated in the same reconcile loop, the change request to the metadata.finalizer is lost when the status is updated first. This requires another loop to then actually delete the finalizer.

See this for a better way to handle updating the status and the body in the same reconciliation loop.

[LalatenduMohanty]

#411 is fixing this.