Added $wgRunJobsAsync to allow running jobs the old way

Added $wgRunJobsAsync to allow running jobs the old way

Adding a new global variable (DefaultSettings.php) named $wgRunJobsAsync, that
defaults to true, to allow installations to force the old synchronous job
execution on page requests instead of the new asynchonous one.

The asynchronous job queue execution was added in 1.22, executing a new shell
script, and it caused major problems for third party installations with restricted
environments or limited system resources, and also because a lot of bugs that went
unnoticed because WMF wikis do not use the on-request job queue.

In 1.23 it was changed to use a new internal HTTP request to a MediaWiki entry point
to perform the request, While some of the bugs were solved, it could still have
performance problems for opening a new process and loading a lot of MediaWiki PHP
objects on it, just to perform a request to see if there are pending jobs and execute
them (it doesn't check if there are jobs to execute). While this may improve speed
on single page requests, because it does not block the execution of the current page,
it has't been thoroughly tested on third party installations. And what is more
important, now there's no way to revert back to the old way of handling those jobs,
as it was done in 1.22 (setting $wgPhpCli = false). This means, in case of major
bugs on the job queue execution due to the new request, there's no way to fix it
other than editing MediaWiki PHP files directly, or completely disable the
on-request job queue handling (some hosts can't set up a cron job for that)

This situation makes it critical to have a safe way to revert to the old job queue
handling, at least until testing that the current implementation doesn't break a lot
of installations.

Bug: 61387
Change-Id: I892a3608228ec0a1c63268fb6180ec679c315980