goversion: rewrite on top of cmd/go/internal/version

[FiloSottile]

Imported the cmd/go/internal/version implementation at
golang/go@c32140f, and restored Symbols and
TextRange to implement the gccgo and crypto checks.

It looks like the amd64 matching had broken, but it should be more
stable to just track what we do upstream with minimal modifications, so
I replaced the core mechanism rather than fixing the matcher.

Fixes #14
Fixes #12
Fixes #11
Fixes #7
Closes #13
Closes #9

[liggitt]

Pulling in the tests from #14, this approach seems to work for go1.13+, but fails for binaries built with older go versions:

go test ./version
--- FAIL: TestReadExe (1.07s)
    --- FAIL: TestReadExe/go1.9.7b4_default (0.12s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.9.7b4_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.10.8b4_default (0.07s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.10.8b4_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.11.13b4_default (0.07s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.11.13b4_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.12.17b4_default (0.10s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.12.17b4_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.9_default (0.01s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.9_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.10_default (0.02s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.10_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.11_default (0.04s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.11_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.12_default (0.04s)
        read_test.go:108: error reading info: not a Go executable
    --- FAIL: TestReadExe/go1.12_stripped (0.00s)
        read_test.go:108: error reading info: not a Go executable

on master, those tests fail on go1.14+ but work for binaries built with older go versions

go test ./version
--- FAIL: TestReadExe (0.09s)
    --- FAIL: TestReadExe/go1.14.6b4_stripped (0.00s)
        read_test.go:108: error reading info: no symbol section
    --- FAIL: TestReadExe/go1.15b5_stripped (0.00s)
        read_test.go:108: error reading info: no symbol section
    --- FAIL: TestReadExe/go1.14_stripped (0.00s)
        read_test.go:108: error reading info: no symbol section
    --- FAIL: TestReadExe/go1.15_stripped (0.00s)
        read_test.go:108: error reading info: no symbol section

[liggitt]

it should be more stable to just track what we do upstream with minimal modifications

that seems more likely to make the identification work for binaries built with the newest go version, but lose the ability to recognize binaries built with older versions

[liggitt]

I think the idea has potential though... would it make sense to just leave multiple implementations in their own packages and try them in turn until one succeeds?

• the existing impl (covering < go1.13) in an internal/legacy package
• the current cmd/go/internal/version impl (covering go1.13+) in an internal/c32140fa package
• at whatever point a change is made in cmd/go/internal/version that requires a new import, bring it into a new package (e.g. internal/014fbff9), leaving c32140fa as-is in case the change would disrupt recognition of 1.13-1.15 binaries

[rsc]

I see no reason whatsoever to delete the old functionality. It works for older versions and those versions are not changing. If you revise the PR to simply add the new checkers without dropping the old ones, I'm happy to merge that.

[mrueg]

@FiloSottile are you planning to make the requested changes to the PR? Would be great to see those changes in.