Move typed queues to ResourceEvent over 'any'

[perdasilva]

Description of the change:
This PR updates our usage of client-go work queues to be kubestate.ResourceEvent typed. Before the change, the queues would accept any comparable datatype, and we had different types flowing through the queues. For instance, for the namespace resolution queue, we had strings as well as ResourceEvents. Using the queue in this meant that we could (and had) the same resource being concurrently reconciled twice: for both the semantically identical string and ResourceEvent items. This in turn led to Subscriptions being put in a terminal UnSat state since the reconciliation that created the install plan (and subsequently the CSV) wasn't finished when the concurrent reconciliation for the same namespace resolved with a seemingly dissociated CSV (i.e. .status.CurrentCSV was empty, but the CSV had been stamped out).

Closes #3010

Motivation for the change:

Architectural changes:

Testing remarks:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Bug fixes are accompanied by regression test(s)
• e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• Docs updated or added to /doc
• Commit messages sensible and descriptive
• Tests marked as [FLAKE] are truly flaky and have an issue
• Code is properly formatted

[joelanford]

All this indirection on getting a key can probably be removed now that we know the item is a ResourceEvent.

[perdasilva]

There's another nutty thing going on here (which I dared not touch). The queue items are in the form
EventResource{type, string} (with the exception of the delete event which carries the object), but the events that get sent to the Sync'ers are in the form EventResource{type, obj}.
So, initial intuition that the syncers worked over old/failed versions of the resources was wrong, because the current version gets picked up and injected here.

Or, did you already get that, and there's a better way to massage this that I'm not seeing?

[perdasilva]

the reason why the delete event doesn't get the same treatment is: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/lib/queueinformer/queueinformer.go#L40.
We may want to revisit this in a follow-up. But, for now, I feel there is sufficient change in this PR that we can let out into the wild before further refactoring.