CRD install and update mechanism

[xavpaice]

Per the design in https://github.com/replicatedhq/troubleshoot/pull/662, design and implement a means to via the troubleshoot CLI:

• Install the CRD defined in #664
• Check installed CRD for availability of new version based on the troubleshoot CLI version
• Upgrade the installed CRD to a new version

This task is specifically to install CustomResourceDefinitions the Custom Object which implement this CRD will be address upgrades in a separate task https://github.com/replicatedhq/troubleshoot/issues/668.

[xavpaice]

ref #668

[chris-sanders]

@adamancini I know you put some thought into this and a common entry point. Can you put those findings/thoughts here so we can discuss if we move this forward.

[adamancini]

we talked about providing a way to give the CRD specs to a user through something like troubleshoot generate-crds but currently building the project produces 3 entrypoint binaries:

• support-bundle
• preflight
• collect

all of which are built to take 1 argument, the path to a spec file

so it begs the question, are there other use cases that might require us to have a common CLI entrypoint?

I imagine we could introduce something like troubleshoot as a parent, and the support-bundle, preflight, and collect binaries could continue to be built as-is (since other projects may embed them)

[chris-sanders]

I'm closing this as we're not planning to proceed with CRDs right now. We might still want to consider a common entry point although this particular issue doesn't drive that need any longer.