Bug 1784567 - Mitigate the unsafety of the GCOV_CHILD_PREFIX support. r=nika

In code-coverage builds we have code which, after `fork` in the child
process, does a number of async-signal-unsafe operations which aren't
permitted in that context.  In particular, locking is a problem: if
another thread in the parent process had held the lock, it will deadlock.

Most of this is conditional on the `GCOV_CHILD_PREFIX` env var being
set, and currently we don't (see bug 1724239), but checking that env var
itself is a problem, because `PR_GetEnv` takes a mutex.  (This was found
by inspection, so I don't know if it's happening in practice, but it's
possible that mysterious timeouts on ccov builds might be caused by this
bug.)

Therefore, this patch moves reading the env var into the parent process,
where it's safe; the rest of the code still contains unsafe operations
(although our `pthread_atfork` hooks in mozjemalloc might help) but it
won't be run.

This will need further cleanup at some point; see bug 1783305.

Differential Revision: https://phabricator.services.mozilla.com/D154572

ipc/chromium/src/base/process_util_linux.cc

@@ -255,6 +255,7 @@ bool LaunchApp(const std::vector<std::string>& argv,
   // Once we switch to gcc/clang 10, we could just remove it in the child
   // process
   void (*ccovSigHandler)(int) = signal(SIGUSR1, SIG_IGN);
+  const char* gcov_child_prefix = PR_GetEnv("GCOV_CHILD_PREFIX");
 #endif
 
 #ifdef OS_LINUX
@@ -301,7 +302,6 @@ bool LaunchApp(const std::vector<std::string>& argv,
     argv_cstr[argv.size()] = NULL;
 
 #ifdef MOZ_CODE_COVERAGE
-    const char* gcov_child_prefix = PR_GetEnv("GCOV_CHILD_PREFIX");
     if (gcov_child_prefix && !options.full_env) {
       const pid_t child_pid = getpid();
       nsAutoCString new_gcov_prefix(gcov_child_prefix);