Right now, any --backgroundtask invocation will process pending updates if it can (namely, when it can take the multi-instance lock). Not restricting made sense when the only background task was backgroundupdate, but less sense when arbitrary short-lived tasks can be sparked.

This ticket tracks makes restricting update processing to backgroundupdate alone.

Try build is percolating at https://treeherder.mozilla.org/jobs?repo=try&revision=8f5a29a63a877632d6521bd6f60c1900e734327e.

I've elected to rename the function from Should... to
ShouldNot..., but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.

This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.

The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate pingsender to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the backgroundupdate task (and the test-only
shouldprocessupdates task).

Depends on D133556

Backed out for causing bustages at nsAppRunner.cpp.

Backout link: https://hg.mozilla.org/integration/autoland/rev/c9fa7cdc9d1359d23988c9805f7c72cb311384cf

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=b78709bc0d0cd7bb20145f7cc18226c0e4189036&selectedTaskRun=ajvnoy3ESHeIGmNAclbV8w.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=361131380&repo=autoland&lineNumber=28200

Sigh, another Linux-only warnings failure. Green try build at https://treeherder.mozilla.org/jobs?repo=try&revision=a10e8fe4054cb5aee9c5bd8298c9c5b2d42825b6, relanding.

https://hg.mozilla.org/mozilla-central/rev/3915b16bab4f
https://hg.mozilla.org/mozilla-central/rev/783fd695e32b