CatalogSource was not getting its .status.connectionState not getting populated

This was observed on a 4.15 ARO cluster - but its likely present on all versions

This issue was brought to us by Andrew Block an Architect that was helping IBM Watson and Adobe. When he came to us, a CatalogSource he had created was not getting its connectionState populated even though the Pod and Service for the source were being created and were fine. The issue continued to be observed even after deleting and recreating the CatalogSource.

In the end, after stepping through the code manually and cross-referencing logs, we discovered that, for some reason, the controller was blind to the source's service account, which had been created previously and not cleaned up.

In the code, the issue was with [this | https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/controller/registry/reconciler/grpc.go#L613] if statement. It was getting triggered by `c.currentServiceAccount(source)`. Even though the service account existed, OLM was blind to it. The code is such that it does not bubble up the error, but rather tried to re-enqueue the CatSrc to get it to create the service account.Interestingly, in the same method (CheckRegistryServer) the first thing it does is check for the service account (though with the live client).

The current conjecture is that the SA did not contain the cache labels introduces by SteveK's work on reducing the OLM footprint.

    1. Create a CatalogSource
    2. Copy the ServiceAccount for the source
    3. Delete the CatalogSource
    4. Edit the ServiceAccount removing all metadata (except name/namespace)
    5. Apply the modified ServiceAccount
    6. Re-create the CatalogSource

    no .status.connectionState

    yes .status.connectionState