Setup a default virtual environment and unconditionally enter it

[jdstrand]

#25969 (comment) says: "This (ed. having influxdb create a default python virtual environment and enter it on start) would be my preference. Many plugins are going to have dependencies that require a venv. And we already have a CLI & API to tell the server to load them. I think it would be a better UX to have everything included so they can just create a trigger and go".

This should be straightforward once #26012 is fixed. Specifically:

0. determine a standard location on the file system for the virtual environment and use it (IMPORTANT: this breaks the "diskless architecture" to a degree
1. see if the default venv exists and if not, have influxdb run /path/to/standalone/bin/python -m venv /path/to/location/of/default/venv
2. source the activate script in /path/to/location/of/default/venv/bin/activate (\path\to\location\of\default\venv\Scripts\activate) and any other setup to enter the venv
3. provide instructions for how users can update the venv manually. Ie:

$ source /path/to/location/of/default/venv/bin/activate
(influxdb3-default)$ pip install foo
...
(influxdb3-default)$ deactivate

4. in the fullness of time, support improved user experiences of setting up the venv (requirements.txt, wrapper commands, etc).

UPDATE: TIL about influxdb3 install package foo so '3' is likely a documentation issue for advanced users.

Other considerations:

• how to keep the venv up to date, if at all
• how to deal with python-build-standalone minor version upgrades (we should be free to upgrade micro versions (eg, 3.11.10 -> 3.11.11 should be presumed safe; but 3.11.11 -> 3.12.x should not). Recall that symlinks/configuration in a venv point back to the runtime that was used to create it. I suspect it is brittle to change the runtime to a new minor version without recreating the venv (would need investigation). One way to handle this is to read the python minor version from the pyvenv.cfg in the venv, compare to the current python used by influxdb and then log a warning. Would need to provide a way to conveniently recreate the environment
• we should be very conservative on pre-installing anything in the venv because users will invariably want different versions of things. Perhaps unconditionally adding uv is worthwhile, but I wonder if we need to support it at all ourselves? (see Consider integrating uv with standalone python builds #26016)
• be cognizant of venv drift in Enterprise (eg, the venvs themselves are drifting due to user changes/etc or the python standalones are drifting because different Enterprise nodes are running different influxdb versions)

Tentatively assigning @jacksonrnewhouse (please adjust as needed).

[jdstrand]

@jacksonrnewhouse - now that I see that this is already implemented, worked with previous Docker builds and now works on non-Windows with updated PATH to address #26012, I'm going to close this.