Support vetting source available license

[lieut-data]

Summary

This change is a prerequisite to introducing the new, Source Available enterprise package within the monorepo, scheduled to contain a (small) subset of the current enterprise functionality.

We currently run go vet with our custom vet tool with two invocations, essentially vetting the server/... package within the monorepo using -license, and then the separate enterprise/... repository using -enterpriseLicense:

	@VET_CMD="-license -structuredLogging -inconsistentReceiverName -inconsistentReceiverName.ignore=session_serial_gen.go,team_member_serial_gen.go,user_serial_gen.go -emptyStrCmp -tFatal -configtelemetry -errorAssertions"; \
	$(GO) vet -vettool=$(GOBIN)/mattermost-govet $$VET_CMD ./...
ifeq ($(BUILD_ENTERPRISE_READY),true)
  ifneq ($(MM_NO_ENTERPRISE_LINT),true)
	$(GO) vet -vettool=$(GOBIN)/mattermost-govet -enterpriseLicense -structuredLogging -tFatal $(BUILD_ENTERPRISE_DIR)/...
  endif
endif

This pull request proposes automatically detecting the new enterprise package at github.com/mattermost/mattermost/server/v8/enterprise and treating it slightly differently for the purpose of vetting the license. In principle, we could support a -sourceAvailable license check, but then we'd need a way to ./... while excluding the enterprise/ package.

The downside to this approach is that we're effectively embedding the major version into this tool, and it will break if we ever bump to v9/. (Though with the new public submodule, it's not really clear we ever "need" to do that.)

Suggestions welcome on better approaches here! Once this is merged, though, I'll push the affected enterprise source to the monorepo.

Ticket Link

None.

[agnivade]

The downside to this approach is that we're effectively embedding the major version into this tool, and it will break if we ever bump to v9/. (Though with the new public submodule, it's not really clear we ever "need" to do that.)

We should bump it to v9 to match with the release version. It's a mistake we haven't done that. @lieut-data - would you like to open a PR to bump that? I'll also check with Amy to add this as a reminder in the checklist for every major version release.

For this PR, could we use a regex to match anything >=8?

[lieut-data]

Using a regex is brilliant! Thanks @agnivade.

On bumping v8/: is there any benefit from doing so? I'm imagining a future where everything we intend to share is in the public submodule and everything else is under internal/. (I realize we can't do that now because enterprise…)

But in that future, do we care about the major version at all anymore? And even now for those clients that still have to import things outside of the public submodule, we almost always recommend pinning at a hash anyway.

Thoughts on just leaving it?

[lieut-data]

/update-branch