Revert "gotooltest: proxy the new GOMODCACHE env var too" (rogpeppe#136)

We started making gotooltest share the host's module download cache with
test scripts, since we did it with GOCACHE and it initially made sense.

However, the upside is significantly smaller for GOMODCACHE compared to
GOCACHE. The build cache can save a significant amount of time, since
many tools have to load or build Go packages as part of their tests.
In contrast, few tests download modules, and those which do tend to
download those modules from a local proxy like goproxytest, which is
very fast already.

The downsides of sharing the module download cache are a few:

* We don't share GOPATH, and since the default GOMODCACHE is
  GOPATH/pkg/mod, sharing one and not the other is unexpected and
  inconsistent.

* Upstream testscript shares GOCACHE, but does not share GOMODCACHE.
  See golang/go#42017.

* Losing a degree of isolation in the tests is a downside in itself,
  especially given that sharing GOMODCACHE isn't crucial.

This reverts commit c5fd45a.

Note that we keep the env.txt test in place, just flipping the
expectation that GOMODCACHE does not contain ${WORK}.

ci: include upcoming go1.16 in build matrix (rogpeppe#124)

testscript: support Go 1.16, move to Actions

https://go-review.googlesource.com/c/go/+/250977 adds a new method to
the testing.testDeps interface, so mirror that here in our no-op
implementation too.

While at it, replace Travis with GitHub Actions, which is faster and
easier to use. We still test on Linux, Mac, and Windows, and with the
two latest Go versions. Otherwise, the config is a straight port, and we
run the same commands.

testscript: relax constraints around actual source in cmp with update (…

…rogpeppe#107)

There are currently constraints on the actual source for a failed cmp
comparison when Params.UpdateScripts is true: the actual must be either
stdout or stderr.

However it's unclear why this constraint is necessary.

Indeed it's a painful constraint when the actual source in a comparison
is file written by a previous command.

Relax this constraint because, after discussion with @mvdan and
@rogpeppe, we believe it is safe to do so.

Add a test for this new logic where the actual is a file that is part of
the archive.

lockedfile: use a retry loop to suppress EDEADLK on AIX and Solaris (r…

…ogpeppe#92)

Apply upstream CL 222277 per @bcmills

Automatically applied via:

(command cd /path/to/go; git diff c6f678b6efd6622d335e6d4b659282bb2d16f5ba~1 c6f678b6efd6622d335e6d4b659282bb2d16f5ba) | git apply -p5

with a minor fix to then use github.com/rogpeppe/go-internal/testenv
instead of internal/testenv

Fixes rogpeppe#91

testscript: provide WorkdirRoot as a new Params field (rogpeppe#87)

Via testscript.Params.TestWork, it is possible for the caller to prevent
the work directories for scripts from being removed once complete.
However the work directories for testscripts are created under a
temporary directory and that working directory is not returned to the
caller of testscript.Run. This makes it impossible for the caller to
programmatically know where the resulting scripts are.

We therefore provide testscript.Params.WorkdirRoot.

WorkdirRoot specifies the directory within which scripts' work
directories will be created. Setting WorkdirRoot implies TestWork=true.
If empty, the work directories will be created inside
$GOTMPDIR/go-test-script*, where $GOTMPDIR defaults to os.TempDir().

Also fix a bug whereby the value of $WORK was not printed as part of the
verbose mode env when Params.TestWork was specified. i.e. it was
impossible to see what the working directory was because all instances
of the working directory value are replaced with the literal $WORK.

testscript: fail a test when a testscript Dir contains no scripts (ro…

…gpeppe#85)

This can happen when either the Dir does not exist, or it is empty.

testscript: make sure work dir isn't removed when -testwork is used (r…

…ogpeppe#80)

When passing -testwork to go test, the work directory shouldn't
be removed.