Discover Support Bundle and Redactor specs in cluster configmaps and secrets

[diamonwiggins]

trafficstars

Expanding the initial feature added in https://github.com/replicatedhq/troubleshoot/pull/709 to discover both support bundle and redactors specs across configmaps and secrets

• Removes the selector flag which complimented the load-cluster-specs flag. It's my opinion that it's okay for this to be a default as I can't really think of a use case where this needs to be changed by an end user. If we did want to add selectors back, then you would need flags for each type eg. SupportBundle, Redactor, etc.

• Based on the code today it made sense to maintain mutlidoc support for standalone redactors found in configmaps or secrets

• However, the multidoc support we have today is confusing. It expects the first document in the file to be a support bundle spec and anything after it can be a redactor. I'm pretty sure if you were to have a mutlidoc with two docs, the first being a redactor and the second being a support bundle, that it wouldn't work. Should we continue supporting this as is today? Should multidocs be able to recognize any order? Do we still even want multidoc support? Should we move to only expect a single type of object in each multidoc? Worth noting that much of this feature isn't documented today and it only impacts the CLIs in this project.

[xavpaice]

I'd prefer that we make sure that existing yaml files with a supportBundle and Redactor type doc, in that order, still work after the change. If we add support for different orders, that's great but not required.

I don't believe that any cluster stored specs will contain multidocs today - Redactors and SupportBundle specs have been stored in ConfigMaps and Secrets, separately, so there's been no need for multidoc there.

Regards removing -l, https://github.com/replicatedhq/troubleshoot/issues/699#issuecomment-1235761525 has some background as to why it was added. I think @emosbaugh might have some thoughts on this and I'd appreciate the advice.

[diamonwiggins]

The current plan after a bit of discussion in today's standup is to continue with the flexibility of being able to use the -l selector, but reuse the same label across both SupportBundle and Redactor so that we don't need to have multiple selectors per type. So the selector will be shared between them.