Refactor Remote Host Collection

[diamonwiggins]

Description, Motivation and Context

Uses a global function in the collect package collect.RemoteHostCollect instead of a method per collector. This prevents the need to make a change to each collector for now until we have a use case that justifies that level ofgranularity

Considerations

While this PR does prevent the need of having to maintain code for each collector, everything awkward about it i'd attribute to the remote collection code not being closely coupled with each collector. Some examples include:

• The RBAC code added. Everywhere else in the codebase this is implemented on a specific type. This code just feels out of place in this implementation, but to be fair, because the same pod is created for each collector its not as dynamic as the other code for standard in-cluster collectors needs to be. We essentially always verify the same permissions(Can I create a Pod/ConfigMap?)
• Host Collector file paths are being derived somewhat arbitrarily. Because this code isn't tightly coupled with each collector, the way the file path in the bundle is being determined is by taking the filename for the collector result, splitting it into directory and filename, inserting the node name between them, and then saving that. For example, host-collector/system/cpu.json becomes host-collector/system/node-name/cpu.json. This works, for now, but again feels strange, and not sure we'll want to do this longterm. Especially since some collector like run have the ability to completely change which file path they use.

TODO

• Needs Tests

Checklist

• New and existing tests pass locally with introduced changes.
• Tests for the changes have been added (for bug fixes / features)
• The commit message(s) are informative and highlight any breaking changes
• Any documentation required has been added/updated. For changes to https://troubleshoot.sh/ create a PR here

Does this PR introduce a breaking change?

• Yes
• No