As a follow up to Bug 1688040, we need to provide to the WebExtensions internals an internal service worker method (e.g. a nsIServiceWorkerManager or nsIServiceWorkerInfo method) to wake up the active worker we are about to forward the extension event to.

This patch includes a set of changes to the ServiceWorker internals to introduce a new
nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals
to request an active background service worker to be spawned (if it is not yet) in response to
a WebExtension API event.

The new method gets as parameters:

• the scope URL for the extension background service worker to spawn
• WebExtensions API namespace and API event name which we are going to spawn an active worker for

and return a promise which would be:

• rejected if the worker could not be spawned
• resolved to a boolean if the worker was spawned successfully (or already running)

The value of the boolean value resolved is meant to represent if the worker did actually
have any listener subscribed for the given WebExtensions API event listener
(which the WebExtensions internals may then use to decide if it is worth to send that event
to be handled by the worker script or not).

In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions
API event was subscribed syncronously when the worker was being loaded is not implemented yet
and it is always returning false (a proposed implementation for that method is going to be
added in a separate patch part of this same bugzilla issue).

A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch
(attached to this bugzilla issue as the child revision for this one).

This patch includes an initial base unit test for the nsIServiceWorkerManager.wakeForExtensionAPIEvent.

Depends on D130756

This patch includes a proposed approach to keep track of the WebExtensions API event listeners
subscribed synchronously while the background service worker script was being loaded and executed,
because this are the listeners that we can assume to be available right after we spawn a worker
and be able to handle the API event that triggered the worker to be spawned.

The information about the "listeners subscribed synchronously while the worker script is being
loaded and executed" is then used by the ExtensionBrowser::HasWakeupEventListener method,
which will be called as part of handling the nsIServiceWorkerManager.wakeForExtensionAPIEvent
call.

Depends on D130757

https://hg.mozilla.org/mozilla-central/rev/3e609b7ad072
https://hg.mozilla.org/mozilla-central/rev/199796d1623b
https://hg.mozilla.org/mozilla-central/rev/a2a67b317de5
https://hg.mozilla.org/mozilla-central/rev/0100cf977ec9