[dev.fuzz] cmd/go: add fuzz timeout flag

[katiehockman]

We may want to consider adding a -fuzztimeout flag, which acts similar to a -timeout flag, but for a run of a single input to the f.Fuzz function.

If -fuzztimeout=100ms, then we give each execution of the fuzz function 100 milliseconds to run, and consider it a crasher if that execution takes longer than 100ms to complete.

Note that libFuzzer does this with a -timeout flag.

We could also consider retrofitting the existing -timeout flag, but that might cause confusion. The description for timeout is "If a test binary runs longer than duration d, panic." If someone sets timeout while fuzzing, we don't want to panic when we hit that timeout (which we will if there is no crash).

Related to #44483.

[AlekSi]

Will https://golang.org/pkg/testing/#T.Deadline be supported?

[jayconrod]

This is done, in the form of the -fuzztime flag.

We should wire that into T.Deadline though as @AlekSi points out.

EDIT: -fuzztime is a global time limit, like -timeout. This issue is about a per-input limit.

[gopherbot]

Change https://golang.org/cl/330509 mentions this issue: [dev.fuzz] testing: report T.Deadline when running seed values

[katiehockman]

It would be nice to support this for 1.18, but it's not a release blocker. We'll see if we get to it.

[jayconrod]

#48157 is a proposal to add a flag and a T method for per-test timeouts. We'll wait for that to be resolved. If approved, we'll use the same flag and method.