cmd/go: consistently defer module path checks (including major-version matching) until import or build-list resolution

[bcmills]

At the moment, we validate that the major version through which a module was resolved matches the major-version suffix of the path declared in its go.mod file.

However, we perform that validation only sporadically (#31428), the resulting failure message (if any) can be difficult to understand in context (#30499, #30636), and a mismatch — even one involving mismatched major-version components — isn't even obviously correct if the module is involved in a replace directive (#26904, #27171 (comment)).

I suspect that we should simply not validate module paths at all when fetching a module, and instead do the validation consistently only at loading time (when we resolve explicit package imports).

At that point:

• If a module is used to replace the source code of another module, we should ensure that its path — including the major-version component — matches the module whose code it replaces.
  • Due to existing replace usage, we might need to relax this to allow the module path to also match the path and version from which the source code was fetched, but ideally only if the go.mod file specifies go 1.12 or earlier.
• If a module is used as an alias from another module path and version (cmd/go: allow replacement modules to alias other active modules #26904), then we should resolve it at the path to which the alias points during package loading, and thus the module path and major version should match that path (and the major version at which it is required).
• If a module is downloaded using go mod download, we don't know how it is going to be used, and thus should not validate anything about its path.

CC @rsc @jayconrod @heschik @hyangah @katiehockman @leitzler @tbpg

[tbpg]

If a module is downloaded using go mod download, we don't know how it is going to be used, and thus should not validate anything about its path.

Can we validate a given module's path and version (with an explicit go.mod) to see if there is a mis-matched major version?

[bcmills]

Can we validate a given module's path and version (with an explicit go.mod) to see if there is a mis-matched major version?

I don't think so, no. It seems entirely reasonable to replace, say, github.com/utensil/spoon/v25 with utensil.dev/fork at v1.0.0, since the two modules have otherwise-distinct import paths and the renaming may have the explicit goal of resetting the major-version numbering.