cmd/go: workspace-mode graph pruning needs to follow upgraded roots #49763
Description
In CL 362754 we added a workspace graph-pruning mode, to fix a bug that we identified through code review (added in the work_prune test script in that CL).
I've been thinking some more about that scenario, and I've identified a related problem arising from the interaction between workspaces and graph pruning.
The module graph in that example has edges like:
example.com/a -> example.com/b v1.0.0 -> example.com/q v1.1.0
example.com/p -> example.com/q v1.0.0
But what if example.com/q itself has edges to new, not-previously-imported dependencies?
example.com/q v1.1.0 -> example.com/r v1.0.0
With current workspace pruning semantics, that edge will be pruned out: it is pruned out of a's dependency graph (because it is not relevant to any package imported by a), and it is not present in b's dependency graph (because b requires a different version of q entirely).
The result is that a by itself may be tidy, and p by itself may be tidy, but loading the dependencies of p from the combined module graph is missing a dependency.