cmd/go: decide where fuzz tooling should live #46311
Description
There are a number of fuzz related tools which we'd like to add, a few examples from among the ideas:
- a tool to convert existing binary input files to the corpus format
- a tool to generate skeleton fuzz targets for a module
- a tool to minimize a corpus to the smallest covering set of inputs
Where should these tools live? One option which seems most obvious would be to keep them under go tool. Another possibility is not to keep them as separate binaries, but to implement their functionality as flags under go test -fuzz.
Putting them under go tool has the benefit of keeping the fuzz testing and tooling code as self-contained as possible, but depending on how many tools we decide on building may begin to pollute the go tool namespace. One other path we could consider is adding a single go tool fuzz tool with subcommands for specific functionality (i.e. go tool fuzz corpusconvert etc).
Putting them under go test keeps everything in one place, but since some of the functionality is disconnected from actually doing any fuzzing it risks overloading the meaning of the flags. Additionally it would mean adding even more functionality to the already complex testing and internal/fuzz packages.