Golang x/tools/gopls: create a go list GOPACKAGESDRIVER for testing

We lack testing for GOPACKAGESDRIVER in gopls, and while we say it is "unsupported", it technically works, and we have a small yet growing user base on bazel or other alternative build systems.

I think we should clarify our level of support for GOPACKAGESDRIVER, and probably commit to some level of basic support.

As a starting point for investigating driver support and fixing bugs, we need a better way to test. We should write a GOPACKAGESDRIVER that simply delegates to go list behind the driver protocol. Unfortunately, current go list support in go/packages has special handling, and does not align perfectly with the driver protocol, so this is not a small amount of work.

CC @adonovan

Comment From: gopherbot

Change https://go.dev/cl/589135 mentions this issue: go/packages/internal/drivertest: a package for a fake go/packages driver

Comment From: adonovan

Gopls invokes go directly from production code, not just tests. For example, these features make use of it: - the GCDetails command (code action disabled by default) invokes go build -gcflags=-json=0,file - the GoAssembly command (new on Friday) invokes go build -gcflags=-S . - the GoTest command (code lens disabled by default) invokes go test.

We haven't really thought about how any these should work with a gopackagesdriver.

The list above is not exhaustive, but many of the other direct calls to go shouldn't arise in a project using an alternative build system: - Hover on go.mod invokes go mod why - Diagnostics on go.mod invokes go mod tidy - the Generate command invokes go generate - various other code actions on go.mod files such as go mod {vendor,tidy,upgrade}.

Comment From: findleyr

It seems clear that we should not offer any of those code actions / code lens with a gopackagesdriver.

Comment From: adonovan

Yeah, it does seem clear. Moved to https://github.com/golang/go/issues/67922.