Bug 1819570 - P2 Save worker's associated BrowsingContextID in channel's LoadInfo for the netmonitor. r=necko-reviewers,valentin

After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.

In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.

In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.

Depends on D174249

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

netwerk/base/nsILoadInfo.idl

@@ -800,6 +800,18 @@ interface nsILoadInfo : nsISupports
   [infallible] readonly attribute unsigned long long browsingContextID;
   [infallible] readonly attribute BrowsingContext browsingContext;
 
+  /**
+   * The BrowsingContext which the worker is associated.
+   *
+   * Note that this could be 0 if the load is not triggered in a WorkerScope.
+   * This value is only set and used in the parent process for some sitautions
+   * the channel is created in the parent process for Workers. Such as fetch().
+   * In content process, it is always 0.
+   * This value would not be propagated through IPC.
+   */
+  [infallible] attribute unsigned long long workerAssociatedBrowsingContextID;
+  [infallible] readonly attribute BrowsingContext workerAssociatedBrowsingContext;
+
   /**
    * Only when the element being loaded is <frame src="foo.html">
    * (or, more generally, if the element QIs to nsFrameLoaderOwner),