feat: make bootstrap=script default for linux

[rickeylev]

wip

DO NOT MERGE:

• See what CI thinks
• Poke feat: support raw symlinks from declare_symlink() bazelbuild/rules_pkg#930
• Maybe: Add a binary-level opt-in/out ?

[rickeylev]

Hrm. CI flagged an issue relating to the runtime-env toolchain: it doesn't respect the virtual env.

This is because the {name}.venv/bin/<interpreter> created is a wrapper script. It's still a symlink, but it points back to a .sh script that calls /usr/bin/python3 "$@". As far as that python interpreter is concerned, it's not in a venv. I remember trying to work around this when I first worked on the venv stuff and couldn't figure out a workaround. This might be the spell the end of the runtime env toolchain.

There's another CI failure relating to compile_pip_requirements, but I haven't had a chance to look yet.

[rickeylev]

note to self:

• This is the interpreter lookup code that needs to be tricked into using venv semantics when a wrapper is used: https://github.com/python/cpython/blob/main/Modules/getpath.py

• PYTHONEXECUTABLE env var works for py3.11+

• exec -a works sometimes. Works for /usr/bin/python3, not for pyenv wrappers

[rickeylev]

Ok, so what I've figured out is:

1. Using exec -a mostly works, but not with pyenv wrappers.
2. Using PYTHONEXECUTABLE envvar works, but only with python 3.11+
3. Because venvs contain the python version in lib/pythonX.Y/site-packages, a mis-match in the build-time python version vs runtime will break the whole app (it's relying on bazel_site_init.py in site-packages to do init).

(1) and (2) mean, in order to use py3.9 with runtime-venv toolchain, the only way to make it even see the venv is to create it at runtime with the typical symlink. This would also solve (3) (symlink lib/python3.11 to python3.10; technically wrong, but matches historical behavior); I can think of some alternatives for (3) that might work right now (PYTHONPATH, addsitedir(), or sys.path setup in stage2), but in order to have a normally functioning venv site-packages dir, we have to create lib/pythonX.Y matching the current runtime version.

Anyways, what I'm thinking is to add something to the toolchain definition that says "recreate the venv at runtime", and then the runtime env toolchain sets this. We already have a flag for this due to rules_pkg not handling raw symlinks. I think having a "create venv at runtime" thing is gonna be a fact of life for awhile, at least until 3.11 is the minimum supported version.