Fix go modules import issues

[AdamSLevy]

• Remove all nested go.mod and go.sum files.
• Add single top level go.mod and go.sum files with module import path
  "github.com/Azure/go-autorest/v15"
• Replace all internal import "github.com/Azure/go-autorest/..." paths
  with "github.com/Azure/go-autorest/v15/..."
• Run go test && go mod tidy

Thank you for your contribution to Go-AutoRest! We will triage and review it as soon as we can.

Fix #481

As part of submitting, please make sure you can make the following assertions:

• [ x ] I've tested my changes, adding unit tests if applicable.
• [ x ] I've added Apache 2.0 Headers to the top of any new source files.
• [ x ] 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.

[msftclas]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ AdamSLevy sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jhendrixMSFT]

Having separate modules it to allow user-code (e.g. adal package) to version independently from code used purely by the code generator (e.g. validation package). I would prefer to fix what we have if possible, and if we conclude it cannot be fixed then we can turn this into one big module.

[AdamSLevy]

I highly encourage you to read up on Golang modules then. From everything I read in the issue I strongly feel that you are trying to fit a square peg in a round hole on this effort. This is further evidenced by the numerous "go_mod_tidy_hack.go" files. Go modules works very well when you work with it, but you are going against the grain. go modules has no way to actually know what to do with these mixed go.mod files that have not been properly kept up to date.

Code that is developed together, is interdependent, and is effectively distributed and released together, needs to be versioned together. A module is intended to version a set of interdependent and co-developed packages together.

But regardless of your opinion on where the API boundaries should lay, the current approach of putting a go.mod file in each sub-package is completely untenable. It is causing rather large headaches downstream, and the intention is not clear to outside developers.

Legitimately asking: Why would I ever want to use two different, possibly incompatible (how would I even know?), versions of the adal code and the validation code? Moreover, why does a user need to import the validation code at all? If they don't, then just move that package to an internal folder, and then make whatever changes you need to it without worrying about changing its API for consumers.

If you aren't ready to have a stable API, that's ok too, but you should re-release this repo under a new import path and stick with a major version of v0, which does not promise any API stability to users.

Additionally version tags allow you to freely develop with breaking API changes on master. go modules will only pull the latest tagged version.

One important rule that you are breaking, is that major version changes require a different import path. This is solved by adding /vXX/ right after the module import path and is based on the repo version tag. But with each package its own module, each not declaring their major version in their own import path in the go.mod file, go mod has no way to know what the version of each sub package should be, or which combinations of interdependent versions are acceptable.

I hope you reconsider changing this repo to be inline with the rules of go modules. At the moment this package is very difficult to use confidently.

[jhendrixMSFT]

Code that is developed together, is interdependent, and is effectively distributed and released together, needs to be versioned together. A module is intended to version a set of interdependent and co-developed packages together.

I agree with this. What I was stating earlier is that not all of the packages in this repo are interdependent and should be allowed to version at their own cadence.

But regardless of your opinion on where the API boundaries should lay, the current approach of putting a go.mod file in each sub-package is completely untenable. It is causing rather large headaches downstream, and the intention is not clear to outside developers.

This is a good point. If we continue to keep multiple modules I believe this can be solved with documentation and examples.

Legitimately asking: Why would I ever want to use two different, possibly incompatible (how would I even know?), versions of the adal code and the validation code? Moreover, why does a user need to import the validation code at all? If they don't, then just move that package to an internal folder, and then make whatever changes you need to it without worrying about changing its API for consumers.

The validation package is used by methods created by our code generator, see here for an example; there's nothing in that package that's useful for SDK consumers. Mixing it (let's call this "non-user code") in with user-consumable code (e.g. auth and to packages are the most common) means that user-code has to pay the tax of a major version bump when a breaking change is introduced in non-user code. It would be ideal to allow user and non-user code to independently version. (Really, the non-user code should have been internal packages in the SDK repo which likely would have avoided this).

One important rule that you are breaking, is that major version changes require a different import path. This is solved by adding /vXX/ right after the module import path and is based on the repo version tag. But with each package its own module, each not declaring their major version in their own import path in the go.mod file, go mod has no way to know what the version of each sub package should be, or which combinations of interdependent versions are acceptable.

All of the modules in this repo are v0 which precludes the need for a major version suffix. This was an intentional decision to test out the current strategy (without introducing any breaking changes due to semantic import versioning), providing a bit of latitude if we need to refactor the module boundaries.

Multi-module repositories are supported, and there is real value in having user and non-user code independently version. So before we just abandon this split I think it's worth due diligence to ensure if it will/won't reliably work.

[jhendrixMSFT]

This has been fixed via #528 which is now in master.