venv site-packages building requires millions of actions

On slack, a user reported that using the venv_site_packages=yes flag caused millions of actions to occur. More user details would help verify its due to the flag.

That said but millions of actions is believable if there are many large targets and the conflict detection ends up having to recreate every file under site-packages. e.g. Given 100 tests (reasonable number), and 50,000 files in their deps (large, but not unheard of), then you end up with 5 million actions. No matter what, bazel is going to have to materialize 5 million files in such a case, but if we have to, at the analysis phase, perform 5M symlink() re-declarations, that's a decent amount of overhead.

At the least, we need to optimize the conflict resolution logic. When I fixed it to handle shared libraries better, I just did a simple and naive implementation. A more optimized version would look for a new minimal set of directories/files to symlink instead of just symlinking all of them. Similarly, runfiles.root_symlinks might come in handy here to avoid most symlink()-to-File action calls.

From slack:

>
> Kris Wilson
> Oct 19th at 8:55 PM
> this also seems to cause the number of actions for a bazel test //... to shoot up into the multi-millions.. which is strange. is this creating one action per symlinked file in the venv? (edited)

Start by reproducing a large test graph with venv_site_packages=yes and inspect the conflict-resolution logic that creates symlink actions. Compare the action count and behavior before and after the optimization; done means preserving package resolution while avoiding millions of redundant file or symlink actions.

Written by the indexing model from the issue text.