Revert commit "don't ever force fork() instead of forkfd()"

This reverts commit d6bf71123d and the
docs from commit 82b75570f0
("QProcess/Linux: fix file descriptor leak in case of failed child
start").

Despite the title of the commit being reverted, the actual consequence
is slightly different: we always use the forkfd() function, but we
change whether we force the use of the fork() library function by use of
the FFD_USE_FORK flag.

Commit 97645478de (5.15) first added the
FFD_USE_FORK flag with a hack to detect whether the setupChild() virtual
might have been overwritten. A configure-time feature to force the flag
was added in commit 2ed99ff5ca (6.0).
Before the 6.0 release, commit d6bf71123d
removed the conditional use of FFD_USE_FORK, with the changelog message
saying "pthread_atfork() callbacks are consistently not invoked".

We've also since added vfork()-like behavior. We tried it for Qt 5.15
and reverted shortly afterwards because we had got the memory semantics
wrong. Commit e1a787a76e (6.5) finally got
it right, for Linux, which revealed another set of problems with
functions used in the child process modifier.

Therefore, we're going to make vfork() and clone() usage opt-in if the
child process modifier is active. This commit is the first part:
disabling their use by default. The flag to opt in will come in Qt 6.6.

[ChangeLog][QtCore][QProcess] Reverted a change from Qt 6.0 that made
the childProcessModifier() callback be run in a child created by means
other than a real fork() library call, a situation in which certain
other library functions would be unusable, unreliable, or cause
deadlocks. A flag to opt in to the solution with better performance will
be added to Qt 6.6.

Task-number: QTBUG-104493
Fixes: QTBUG-111243
Fixes: QTBUG-111964
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d3e66843e5a29
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

src/corelib/io/qprocess.cpp

@@ -1588,15 +1588,6 @@ std::function<void(void)> QProcess::childProcessModifier() const
     "async-signal-safe" is advised). Most of the Qt API is unsafe inside this
     callback, including qDebug(), and may lead to deadlocks.
 
-    \note On some systems (notably, Linux), QProcess will use \c{vfork()}
-    semantics to start the child process, so this function must obey even
-    stricter constraints. First, because it is still sharing memory with the
-    parent process, it must not write to any non-local variable and must obey
-    proper ordering semantics when reading from them, to avoid data races.
-    Second, even more library functions may misbehave; therefore, this function
-    should only make use of low-level system calls, such as \c{read()},
-    \c{write()}, \c{setsid()}, \c{nice()}, and similar.
-
     \sa childProcessModifier()
 */
 void QProcess::setChildProcessModifier(const std::function<void(void)> &modifier)

src/corelib/io/qprocess_unix.cpp

@@ -471,6 +471,8 @@ void QProcessPrivate::startProcess()
 #if defined(Q_OS_LINUX) && !QT_CONFIG(forkfd_pidfd)
     ffdflags |= FFD_USE_FORK;
 #endif
+    if (unixExtras && unixExtras->childProcessModifier)
+        ffdflags |= FFD_USE_FORK;
 
     pid_t childPid;
     forkfd = ::vforkfd(ffdflags , &childPid, execChild2, &execChild1);