Now that views are immutable, we can simplify the invalidation of
imports state. The imports.ProcessEnv can also be immutable, and we need
only invalidate module state (i.e. dependencies) if a go.mod file
changes.

While at it, add documentation and perform some superficial cleanup in
the internal/imports package. This is a first step toward larger state
optimizations needed for the issues below. TODOs are added for remaining
work.

For golang/go#44863
For golang/go#59216

Change-Id: I23c1ea96f241334efdbfb4c09f6265637b38f497
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559496
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>

In CL 508506, we missed a performance regression because there were no
benchmarks for goimports' initial scan: the only scan benchmark related
to re-scanning, which doesn't recursively descend into all module cache
directories.

Add a benchmark for the initial scan.

For golang/go#44863

Change-Id: I94ec8b2b0df468fd06a1316f24c00d5f47c2f5c9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/561436
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

This restores the concurrent walking that was removed in CL 508506,
since that concurrency turns out to actually matter in practice
(see golang/go#44863), but uses a different (and in my opinion simpler)
concurrency pattern based on the one shown in my 2018 GopherCon talk
(https://drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view,
slide 114), and removes the arbitrary 4-goroutine minimum.

On my machine this speeds up the benchmark from CL 561436
by a factor of around 3½.

	goos: linux
	goarch: amd64
	pkg: golang.org/x/tools/internal/imports
	cpu: Intel(R) Xeon(R) CPU @ 2.20GHz
	                              │  before.txt  │              after.txt              │
	                              │    sec/op    │   sec/op     vs base                │
	ModuleResolver_InitialScan-24   1728.0m ± 5%   505.2m ± 7%  -70.76% (p=0.000 n=10)

Fixes golang/go#65531.
Updates golang/go#44863.

Change-Id: I082bb3375f7775d55d130bf75ae71f53312aace1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/561675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>

When using the gopls daemon, or with the multi-View workspaces that will
be increasingly common following golang/go#57979, there is a lot of
redundant work performed scanning the module cache. This CL eliminates
that redundancy, by moving module cache information into the cache.Cache
shared by all Sessions and Views.

There should be effectively no change in behavior for gopls resulting
from this CL. In ModuleResolver.scan, we still require that module cache
roots are scanned. However, we no longer invalidate this scan in
ModuleResolver.ClearForNewScan: re-scanning the module cache is the
responsibility of a new ScanModuleCache function, which is independently
scheduled. To enable this separation of refresh logic, a new
refreshTimer type is extracted to encapsulate the refresh logic.

For golang/go#44863

Change-Id: I333d55fca009be7984a514ed4abdc9a9fcafc08a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559636
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>