🐛 Switch queue informer to use types.Namespace name; relocate deletion handler

[joelanford]

Description of the change:

This PR addressed the #3010. The root cause of the issue was that the workqueue backing the QueueInformer was processing different types: string, and ResourceEvent. This led to concurrent processing of the same resource causing the Subscription to get mangled. To address this issue, this PR:

1. pins the workqueue to process NamespaceName
2. moves deletion handling to the QueueInformer
3. removes the ResourceEvent type
4. updates the Subscription sync'er (and its metrics handling) to reflect the removal of ResourceEvent.

The reason for 2. is that the Sync function expects the resource as a parameter. The code does not add finalizers to resources or appropriately handle resource deletion. We judged that change to be too risky and opted for this solution. This means there is still the possibility that a delete and update event could be handled concurrently. We don't think this will be a problem because either worker won't be able to pull the resource from the index (it was deleted), and will be discarded, or the update handler will hit a resource not found error as the resource is no longer in etcd anyway. Far from ideal, but it doesn't make the current behavior worse, and it solves concurrent resource update handling, which is the source of the problem anyway.

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