## Summary ##
(FetchLater is a flag-guarded new API)
Aborting is implemented by propagating a custom mojo disconnection
reason from remote<URLLoader> (renderer) to receiver<URLLoader>
(browser).

Unlike previous approach [1], this CL does not introduce new IPC. So
there should be no IPC sequencing issue.

## Before this CL ##
The `KeepAliveURLLoader` in browser starts all pending requests when
it learns the disconnection of its receiver<URLLoader>.

## After this CL ##
By default, it will still start pending request on disconnection of
receiver<URLLoader>. However, if the disconnection comes with a custom
reason of pair (kClientDisconnectReason,
                kFetchLaterDisconnectReasonExplicitlyAborted), the
pending request will be aborted instead.

## Details ##
Every time JS abort() call happens for a FetchLater request,
the following extra flow is executed:

```
FetchManager::Loader::Abort()
->ThreadableLoader::Abort()
->ResourceLoader::AbortFetchLaterRequest()
->ResourceLoader::Cancel()
->(Calls to blink::URLLoader/ResourceRequestSender in between...)
->ResourceRequestSender::DeletePendingRequest()
->ThrottlingURLLoader::CancelWithError(
    ..., kFetchLaterDisconnectReasonExplicitlyAborted)
```

`ResourceRequestSender` is able to learn that it is deleting an
aborted FetchLater request by asking
`FetchLaterLoaderHelper::IsExplicitlyAborted()` it holds, which is a
new interface implemented by the `ResourceLoader` that creates itself.
The helper is only provided to `ResourceRequestSender::SendAsync()`
when the request is a FetchLater request.

[1]: https://crrev.com/c/4803083/23..29/third_party/blink/renderer/core/fetch/fetch_manager.cc#b1096

Bug: 1465781
Change-Id: I8762c37e1c64b3661d760cfb62f0ea8f02dddf1c