feat(host-collector): add progress for host collector

[DexterYan]

Description, Motivation and Context

• using CollectorProgressCallback to allow host remote collector to send progress back to kotsadm
• allow collectorCB to be used as CollectorProgressCallback in remote host collector. https://github.com/replicatedhq/kots/blob/a57ff2d1431d961808c2bbfdf0997abe25ab0e34/pkg/supportbundle/execute.go#L167
• use supportBundleProgressUpdate match the callback type to report the progress in https://github.com/replicatedhq/kots/blob/a57ff2d1431d961808c2bbfdf0997abe25ab0e34/pkg/supportbundle/execute.go#L79

kots demo
Library | Loom - 24 October 2024 - Watch Video

sc-114419

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

[nvanthao]

Just add my thoughts,

I see we are using opts.CollectorProgressCallback because KOTS uses that callback to touch-up the the progress update.
So this change will have minimal impact to KOTS.

A right way I think, is not to use the callback, but to send into opts.ProgressChan a public struct collect.CollectProgress, and KOTS, as a consumer, will just use it. This will decouple KOTS and troubleshoot, no callback needed.

I see that we are already doing it for preflight

https://github.com/replicatedhq/kots/blob/99b056171e307ae50831d9ac9ddc71b91c84c12f/pkg/preflight/execute.go#L39-L53

That being said, KOTS will have to refactor with more code changes to cater for using collect.CollectProgress

[nvanthao]

Let's go with it now and we will have a separate card to refactor the progress logic in KOTS