Fix Go module ambiguous import errors

[miquella]

• I've tested my changes, adding unit tests if applicable.
• I've added Apache 2.0 Headers to the top of any new source files.
• I'm submitting this PR to the dev branch, except in the case of urgent bug fixes warranting their own release.
• If I'm targeting master, I've updated CHANGELOG.md to address the changes I'm making.

---

This is an extension of the mitigations introduced in #455. Unfortunately, the original mitigations didn't address the primary cause of ambiguous import errors: the github.com/Azure/go-autorest module.

The issue stems from the fact that old versions of the root module (github.com/Azure/go-autorest) provide the same packages as the newer submodules.

To correct this situation, the root module needs to be upgraded to a version that no longer provides those packages (a version where the submodules are present). Fortunately, the submodules can be leveraged to provide the necessary version bump.

See also: #414 (comment)

---

Caveat: in order for this to work, an importable version of the root package needs to be referenceable.

PR #527 makes the root package importable. It was submitted separately to allow it to be released before this PR is merged.

The go.mod files assume that this importable version will be referenceable as v14.2.0. If the version where the importable package is available ends up being different, these files will need to be updated.

See also: #395, #413, #414, #455, #481, #524

[miquella]

Upgrading to a version of a submodule that includes this fix should resolve any latent "ambiguous import" errors.

[miquella]

@jhendrixMSFT: I believe this will resolve the "ambiguous import" errors that keep getting reported 🤞

[jhendrixMSFT]

Thanks for putting this together, I believe you're right. Given that this is difficult to test, I'm going over docs and trying to find other examples to convince myself this is correct and won't make things worse (which is my bigger fear).

[miquella]

I very much agree that I don't want to make things worse! 😅

In light of that, I was actually very careful to not modify the go.mod files directly. Instead, I updated the go_mod_tidy_hack.go files to reference the root module (and added a few missing go_mod_tidy_hack.go files), then did the following in each submodule directory:

1. go mod edit -require github.com/Azure/go-autorest@v14.2.0+incompatible
2. go mod edit -replace github.com/Azure/go-autorest=$HOME/src/github.com/Azure/go-autorest (since version v14.2.0 doesn't exist yet, we have to use a temporary replacement)
3. go mod tidy -v
4. go mod edit -dropreplace github.com/Azure/go-autorest

This was modeled directly after the procedure outlined in the commit message mentioned by @bcmills in #414.

---

As a small bit of background: I was chatting with @jayconrod in the Gophers Slack yesterday and something he said tipped me off (emphasis mine):

In order to avoid this ambiguity, we recommend when splitting a project into submodules that each submodule requires the original module at a version after the split. That way, the author can guarantee that each package is provided by no more than one module.

After reading that and then re-reading the discussion in #414, I am reasonably confident in this solution.

[jhendrixMSFT]

I'm working on validating this today, assuming all goes as planned should have both your PRs merged EOD.

[miquella]

Sounds great! If there's anything else I can help with or explain, please let me know.

[jhendrixMSFT]

Fixes #481

[miquella]

I just wanted to follow up to confirm that upgrading to the versions of the submodules released today immediately resolved the ambiguous import errors I was running into.

Thank you, again, for helping get this through, @jhendrixMSFT!