<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
  * `<=v10.1.3`
* **Operating System:**
  * All
* **Last Known Working Electron version:**
  * N/A

### Expected Behavior
Redirect handling for non-GET requests in scenarios where HTTP/HTTPS requests are intercepted using the `interceptHttpProtocol` and `interceptStreamProtocol` handlers should follow the same standards as non-intercepted requests. This should be true for `BrowserWindow`, `BrowserView` and `webview`. For example, the following is an example of `GET` request being redirected and the subsequent request thereafter:

```http
client> GET / HTTP/1.1
client> Host: foo.com
client> 
client> 
server> HTTP/1.1 302 OK
server> Location: http://foo.com/new
server> Content-Length: 0
server>
server>
client> GET /new HTTP/1.1
client> Host: foo.com
client>
client>
```
The same should be true for non-GET requests that result in redirections (with exceptions listed here: [https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections)):

```http
client> POST /form HTTP/1.1
client> Host: foo.com
client> Content-Length: 3
client> Content-Type: application/x-www-form-urlencoded
client> 
client> a=b
server> HTTP/1.1 302 OK
server> Location: http://foo.com/new
server> Content-Length: 0
server>
server>
client> GET /new HTTP/1.1
client> Host: foo.com
client>
client>
```

Furthermore, the developer tools should display all the requests and responses that occurred (1 entry per request/response pair).

### Actual Behavior
Redirect handling for non-GET requests in scenarios where HTTP/HTTPS requests are intercepted using the `interceptHttpProtocol` and `interceptStreamProtocol` handlers are NOT following the same standards as non-intercepted requests. This is what happens, instead, with all 3xx responses:

```http
client> POST /form HTTP/1.1
client> Host: foo.com
client> Content-Length: 3
client> Content-Type: application/x-www-form-urlencoded
client> 
client> a=b
server> HTTP/1.1 302 OK
server> Location: http://foo.com/new
server> Content-Length: 0
server>
server>
client> POST /new HTTP/1.1
client> Host: foo.com
client> Content-Length: 3
client> Content-Type: application/x-www-form-urlencoded
client> 
client> a=b
```

This breaks interaction with a lot of websites; especially in scenarios where client authentication is being processed. For example, logging into Github.com successfully results in a 302 in scenarios where two factor authentication is required. The current implementation (without introducing some awful hacks) would break this interaction. 

Furthermore, it appears that 3xx responses are expected to be resolved prior to returning data to the interceptor callback. This creates an inconsistency in the Developer Tools network tab where 3xx responses automatically resolve to the final response code (i.e. 200) if the interaction resulted in a successful redirection. Meaning, the redirect request, response pair is lost in the log.

### To Reproduce

TBD

### Screenshots

The following screenshots demonstrate the issue using a login sequence on GitHub. After initial login request, the server redirects me to the 2FA form which is at `/sessions/two-factor`. The following is what happens when I don't implement redirection detection hacks:

![Failed Login Without Redirection Hack](https://user-images.githubusercontent.com/618125/95768170-e65c7480-0c83-11eb-9c2c-7afe7f9b1bf5.png)

As can be seen, the redirect returns a 422 because the method and body remained unchanged during in the redirecting handling routine.

And the following demonstrates the proper result in the GUI with redirect detection hacks to modify the original request into a `GET` without a body, however, the developer tools network tab does not show an entry for the redirect/response pair to `/sessions/two-factor`:

![Login With Redirection Hack but No Developer Tools Network Entry](https://user-images.githubusercontent.com/618125/95767909-7fd75680-0c83-11eb-8bcc-59a9cf56a06d.png)

As can be seen in the image above, the only request is to `/session` and the redirect gets handled internally and resolved to a 200 once the redirect has completed successfully.

### Additional Information

TBD

shell/browser/net/electron_url_loader_factory.cc
}
    return;
  }
  
  if (dict.IsEmpty() && ResponseMustBeObject(type)) {
    OnComplete(std::move(client), request_id,
               network::URLLoaderCompletionStatus(net::ERR_NOT_IMPLEMENTED));
    return;
  }
  switch (type) {
    case ProtocolType::kBuffer:
      StartLoadingBuffer(std::move(client), std::move(head), dict);
      break;
    case ProtocolType::kString:
      StartLoadingString(std::move(client), std::move(head), dict,
                         args->isolate(), response);
      break;
    case ProtocolType::kFile:
      StartLoadingFile(std::move(loader), request, std::move(client),
                       std::move(head), dict, args->isolate(), response);
      break;
    case ProtocolType::kHttp:
      StartLoadingHttp(std::move(loader), request, std::move(client),
                       traffic_annotation, dict);
      break;
    case ProtocolType::kStream:
      StartLoadingStream(std::move(loader), std::move(client), std::move(head),
                         dict);
      break;
    case ProtocolType::kFree: