Switch go_modules from getUpdatedVersion to a public go command

[jeffwidman]

See discussion here: #3590 (comment)

In particular:

there's a lot of custom code whose sole goal is to identify what the latest version of a go module. That's the only reason we need https://github.com/dependabot/dependabot-core/blob/main/go_modules/helpers/updatechecker/main.go which is the only reason we need an entire repo: https://github.com/dependabot/gomodules-extracted/.

And @thepwagner pointed out:

I think something like go list -m -mod=mod -versions -json <dep> is a better solution than the current getUpdatedVersion helper. I've experimented with it here: https://github.com/thepwagner/action-update-go/blob/2ba2b9a3d49a3285b327622fbd5daccb4fe64e19/gomodules/check.go#L141 .

The one thing to note is that go list, go get etc download modules. I'm not sure the existing getUpdatedVersion does that. I haven't looked into how it works. But from a speed/network chattiness, avoiding downloading modules is a big win. Although on the flip side, from a correctness point of view, public APIs like go list, go get etc will probably do a better job of navigating any issues such as retracted versions, pre-release versions, etc.

Also the guts of how all that upstream code works, regardless of whether accessed via getUpdatedVersion or go list and friends, is going to change a lot in go 1.17 when lazy module loading lands. That may also greatly affect correctness/speed, unclear at this point.

Fixing this would implicitly fix #3569.

[thepwagner]

This was investigated and decided against (or at least: deferred) in #3630

[jeffwidman]

Completely agree that given the current behavior this isn't the right move.

However, this is probably worth holding open until golang/go#36460 lands, as it may change the behavior. See #3630 (comment).

[jeffwidman]

This was done as part of #4434