rfc: protocol handling enhancement

[nmggithub]

This is very much a work-in-progress, but I am opening it up so we have a centralized place to discuss these things that's not my PR.

To briefly give my personal answers to the questions posed:

• Is protocol.handle meant, by us, to be an middleware-like interception API or a provider API for the https scheme? Not sure, I didn't make it.
• Should protocol.handle be split into two different API's (e.g. protocol.handle and protocol.intercept)? Splitting might be better, if we want to support more middleware-like features.
• In the case that a more middleware-like interception API is desired:
  • Should we allow for the intercepted request to be modified before a potential fallback? Would be nice in concept, hard to implement (especially if the in-flight request is used for the fallback).
  • Should we allow for the returned response to be modified before passing it along? Could be easier to implement than request modification, but poses questions about side-effects.
  • Should the "fallback to Chromium" option use the in-flight request or dispatch a new one? A more-aligned fallback should use the in-flight request.
  • Should setting the Set-Cookie header in a returned response set the cookies? Would be nice in concept, hard to implement (when and where would the API commit to applying the cookies?).
  • Should layered handlers (middleware-like) be supported? Simple enough in concept, but side-effects may make things difficult to implement.
• What should happen to the webRequest handlers API? Perhaps deprecated if their behavior can be superseded by any new API?