bump up the troubleshoot version to v0.72.x

[arcolife]

What this PR does / why we need it:

bump up the troubleshoot version to v0.71.1

Which issue(s) this PR fixes:

Fixes SC-87575

Special notes for your reviewer:

• Follow-up from bump up the troubleshoot version to v0.71.1 #4029
• Turns out, for tests to kick in, a PR should be raised from a feature branch in upstream rather than the fork.
  (🙇🏼‍♂️ @cbodonnell for the hint!).
• Visual smoke tests on okteto went well (uploading a license to admin portal and running analysers).

Steps to reproduce

Does this PR introduce a user-facing change?

NONE

Does this PR require documentation?

NONE

[xavpaice]

Currently blocked by replicatedhq/troubleshoot#1331, we'll need to integrate the version that has the fix

[arcolife]

• v0.72.1 released, but uses a new version of github.com/Azure/azure-sdk-for-go/sdk/azcore in chore(deps): bump github.com/microsoft/go-mssqldb from 1.5.0 to 1.6.0 troubleshoot#1335.
• OTOH, KOTS is using version v0.21.1 due to the replace directive in its go.mod file, which cancels the indirect requirement version.
• This leads to an error in go mod tidy after bumping troubleshoot itself.

go: finding module for package github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud
go: github.com/replicatedhq/kots/pkg/kotsutil imports
        github.com/replicatedhq/troubleshoot/pkg/collect imports
        github.com/microsoft/go-mssqldb tested by
...
        github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud: module github.com/Azure/azure-sdk-for-go/sdk/azcore@latest found (v1.7.2, replaced by github.com/Azure/azure-sdk-for-go/sdk/[email protected]), but does not contain package github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud

Here on, if you try to solve for tidy, it works out eventually, by commenting out

+       // github.com/Azure/azure-sdk-for-go/sdk/azcore => github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1
+       // github.com/Azure/azure-sdk-for-go/sdk/internal => github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3

but then make test fails:

# github.com/Azure/azure-sdk-for-go/sdk/storage/azblob
../../../../go/pkg/mod/github.com/!azure/azure-sdk-for-go/sdk/storage/[email protected]/zc_blob_lease_client.go:25:16: undefined: to.StringPtr
...
go/sdk/storage/[email protected]/zc_shared_policy_shared_key_credential.go:190:17: undefined: log.EventResponse

so now we're dealing with azure's storage/azblob which when I try for its latest release bump, cracks:

github.com/vmware-tanzu/velero/pkg/util/logging
../../../../go/pkg/mod/github.com/vmware-tanzu/[email protected]/pkg/util/logging/kopia_log.go:35:10: cannot use &kopiaLog{…} (value of type *kopiaLog) as *zap.SugaredLogger value in return statement
# github.com/kopia/kopia/repo/blob/azure
../../../../go/pkg/mod/github.com/kopia/[email protected]/repo/blob/azure/azure_storage.go:27:17: undefined: azblob.ServiceClient
../../../../go/pkg/mod/github.com/kopia/[email protected]/repo/blob/azure/azure_storage.go:28:17: undefined: azblob.ContainerClient

which is when I gave up. Don't think we should be bumping dep versions to fix go mod tidy like that. Not sure about where to go from here atm.

• May need to start vendoring but that'll affect the size of our git repo.
• And because go.mod has a lot of "replace", this dep tree is now becoming unstable with many deps running way behind on versions.

[cbodonnell]

@arcolife The key issue was the bump of github.com/microsoft/go-mssqldb to v1.6.0 brought in by the latest troubleshoot go module. github.com/microsoft/go-mssqldb depends on github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud, which does not exist in v0.21.1. Other than this, we are OK and since KOTS does not depend on troubleshoot functions using github.com/microsoft/go-mssqldb, we can pin github.com/microsoft/go-mssqldb at the existing v1.5.0 version and it will build:

github.com/microsoft/go-mssqldb => github.com/microsoft/go-mssqldb v1.5.0

For some context, we have pinned these Azure dependencies to older versions because we also import Velero to support configuring snapshots in KOTS. Velero's go.mod: https://github.com/vmware-tanzu/velero/blob/v1.10.1/go.mod#L60-L62

There are likely some replace directives outside of this that we could get rid of, but I agree with you that it's out of scope of this PR.

[arcolife]

since KOTS does not depend on troubleshoot functions using github.com/microsoft/go-mssqldb

@cbodonnell Thanks for the confirmation. I've pinned it with a comment and if the tests pass (eventually), we're good to go!

For pruning, I've opened another issue here #4045