gh-91401: Add a failsafe way to disable vfork.

[gpshead]

Just in case there is ever an issue with _posixsubprocess's use of
vfork() due to the complexity of using it properly and potential
directions that Linux platforms where it defaults to on could take, this
adds a failsafe so that users can disable its use entirely by setting
a global flag.

No known reason to disable it exists. But it'd be a shame to encounter
one and not be able to use CPython without patching and rebuilding it.

See the linked issue for some discussion on reasoning.

[vstinner]

Why not a simple boolean flag?

Can subprocess disable vfork using disable_vfork_reason if vfork is not available? You can expose a simple private flag in _posixsubprocess saying if vfork is available. Something similar to _testcapi.WITH_PYMALLOC or _thread.TIMEOUT_MAX.

[vstinner]

I added subprocess._USE_POSIX_SPAWN so people can opt-out if they encounter problems with posix_spawn().

[gpshead]

I added subprocess._USE_POSIX_SPAWN so people can opt-out if they encounter problems with posix_spawn().

Being consistent with that seems worthwhile, I'll rework this PR. I expect I'm overthinking it with the whole "make it a string" thing and pleading for people to include an explanation of why.

[vstinner]

I chose to add a private attribute since the default value must be safe for all users. But for the corner cases, IMO a private attribute is enough.

For vfork, well, it's up to you to add a private or public attribute.

[vstinner]

LGTM. I just have a doubt about the doc format, but you will see when it will be rendered on docs.python.org.

[vstinner]

I never tried this syntax, I don't know if it's properly rendered. You will see :-)