`webRequest` API alignment and support in MV3

The webRequest API future is uncertain and currently not aligned among browser vendors. It's been communicated that the non-blocking webRequest API would be supported for MV3 by Chrome as well as Firefox for MV3. Chrome currently has a bug ticket open related to fixing this issue, Firefox is yet to have an MV3 implementation, and Safari surfaces an error in Safari Technology Preview on extension install, "An extension with a non-persistent background page cannot listen to webRequest events". I believe this issue is separate from https://github.com/w3c/webextensions/issues/148 as this is specific to MV3 and the future of webRequest and DNR as a replacement.

I've listed specific points with use cases for some exposing either misalignment or lacking support which I'm hoping we can resolve and have clear communication about to clarify the current state and planned future of this API for MV3 to fit developers needs.

• Performance (Google, Mozilla, and Apple have all communicated the impact of performance in supporting this API as it is heavy and would inherently mean the service worker is kept alive indefinitely. Mozilla has the intention to not have an arbitrary limit on service workers, Google is intent on having this limit which is currently around 5 minutes.)
• Non-blocking (Not supported in any MV3 implementation currently available, there is the short-term support of this API that seems to be agreed on by Google and Mozilla, but it's uncertain where Apple stands on this subject and overall what the future will look like as all are pushing for DNR to replace it but is incomplete)
• Blocking (Only Mozilla has voiced their intention to keep supporting blocking webRequest, Google has specifically said this wont be supported but there are use cases that aren't yet handled by Declarative Net Request)
• Declarative Net Request (DNR currently doesn't cover all of the use cases that are supported by webRequest, both blocking and non-blocking. There are other limitations associated with DNR, an example being number of rulesets that can be declared.)

Example of unsolved use cases

• Basic access authentication (To fill a credential in a form requiring basic access authentication we rely on "Provide credentials asynchronously" which uses blocking webRequest.onAuthRequired and which DNR does not replace.)
• Iframe Id extraction (Using non-blocking web requests is the only way we have found at the moment to get both the frame id and the parent frame id of a given frame. This is something we absolutely need for the page analysis, as it allows us to build a full structure of the page, iframes included. We may not need this anymore in the future, if this other proposal is implemented in Chrome and Safari. This has already been implemented in Firefox but I believe there were reservations on the Chrome side for unknown reasons. Because we don't have direct access to the request and subsequently the frame ids via DNR it's not an option for replacing.)

Start by reviewing the linked Chrome bug, the referenced issues 148 and 12, and the browser-specific MV3 positions described in this issue. Compare the listed performance, blocking, non-blocking, DNR, authentication, and iframe use cases across Chrome, Firefox, and Safari. Done means the current support and intended future of webRequest in MV3 are clearly documented or resolved by the relevant standards discussion.