fzgo should support modules now that dvyukov/go-fuzz supports modules

[thepudds]

dvyukov/go-fuzz supports modules now (https://github.com/dvyukov/go-fuzz/pull/274), so it is now feasible to support modules with fzgo.

[thepudds]

Note that modules can usually be fuzzed by placing the code under test in the proper locations in GOPATH and explicitly disable module mode for cmd/go by setting GO111MODULE=off, as described in the Install section of the readme:

https://github.com/thepudds/fzgo#install

[thepudds]

For full-blown modules support, there are at least three issues.

The first issue is that in modules mode, cmd/go rejects the temporary richsigwrapper package with the following error (in this case, when trying to fuzz the podcast module with module mode enabled):

fzgo: instrument podcastfuzz.Fuzz_EnclosureType_String error: getting cache dir failed: fzgo cache hash: go list -deps: exit status 1: can't load package: package richsigwrapper: malformed module path "richsigwrapper": missing dot in first path element

If we resolve that, the second issue is we might need to create a temporary go.mod within the temp working directory for something like fzgo.tmp/richsigwrapper with a directory-based replace back to the original code under test. (Otherwise, richsigwrapper would not know how to locate the code under test, which can no longer be assumed to be in GOPATH). This would mean locating the go.mod file for the code under test to use as the target of the directory-based replace, and either parsing it to learn to the module name, or perhaps executing something like go list -m to get the module name to use on the left side of the replace.

A third issue is the code under test might itself have replace directives in its go.mod. To start, we could detect and error out in that case and not support that. Alternatively, we could attempt to move the replace directives from there to the temporary go.mod for fzgo.tmp/richsigwrapper. One wrinkle would be replace targets that are relative directories. We could error out for that, or resolve to absolute paths when we move the replace to the temporary go.mod for fzgo.tmp/richsigwrapper. (Sidenote: doing that here could be a precursor to adding similar logic to dvyukov/go-fuzz to insulate it against GOPATH perhaps going away someday).

Maybe?

A completely different approach would be to completely materialize the modules world view into an equivalent GOPATH. That would be a bigger change, and less of a step forward.