As per the title. The plan is to enable the fork server in builds while keeping it off at runtime with this pref; then when we're sure we have fully stabilized it we'll turn it on by default.

While you're there, could you move the configure flag in toolkit/moz.configure?

Backed out part2 for multiple failures e.g assertion failures, leaks

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=84184c894e33a8711d1f5b0013619eb7714bda7b&selectedJob=288570815

Failure log:

• assertion: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=288570815&repo=autoland&lineNumber=1400
• leak: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=288570809&repo=autoland&lineNumber=4446
• python mozbuild: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=288570809&repo=autoland&lineNumber=4446

Backout: https://hg.mozilla.org/integration/autoland/rev/584f0d57a0efe35658674d0e8d23f27a11114ae1

https://hg.mozilla.org/mozilla-central/rev/a6060b962c80

Move fork server launcher to app-startup instead of xpcom-startup.

Accessing StaticPrefs at xpcom-startup is too early to cause the
initialization of it. The preferences from user.js and profile are
not load yet. So, later, it would cause error of changing the value
of static prefs that is marked as mirroring once.

https://hg.mozilla.org/mozilla-central/rev/19b4dadd16f4
https://hg.mozilla.org/mozilla-central/rev/638974f6efd0

clear ni