Introduce WebNavigationBodyLoader

WebNavigationBodyLoader interface (and two implementations)
will be used for loading navigation response body, instead of
going through WebURLLoader. This patch only contains the
implementation, but does not include the usage just yet.

WIP usage can be seen here:

The advantages of a separate code path for navigations:
- Possible to commit navigations synchronously, instead
  of waiting for RawResourceClient callbacks from the loader.
  This is a primary motivation.
- Makes it easier to Onion Soupify navigation code separately
  from loading code.
- All navigation-related special cases can be handled directly
  in DocumentLoader now.
- We don't need a "replay fake request" mode in loader anymore.
- We stop abusing ResourceRequest/ResourceResponse for navigation
  information (e.g. RequestorOrigin, OriginPolicy and many more).

- Two URLLoaderClient and body pipe consumer implementations
  to maintain.
- Future loading features might have to touch navigation body
  loader as well. Although most of the navigation-related features
  currently have to touch navigation url request in the browser,
  there is a small chance that NavigationBodyLoader will be
  affected as well.

Larger cleanups possible after this:
- Remove ResourceType::kMainResource and any code related to it.
- Remove ResourceRequest::GetFrameType and any code related to it.

Ideally, NavigationBodyLoader could be implemented directly in Blink,
but there are some dependencies on resource load statistics in content.
Also, Blink is not quite ready to talk to Network Service directly.

This patch corresponds to step 6.g of the doc linked in the bug.

Bug: 855189
Change-Id: I3ac7b33db60e7b50e583e2006dd194c4bf843921
Commit-Queue: Dmitry Gozman <>
Reviewed-by: Kinuko Yasuda <>
Reviewed-by: Daniel Cheng <>
Reviewed-by: Arthur Sonzogni <>
Reviewed-by: Yutaka Hirano <>
Reviewed-by: Mythri Alle <>
Cr-Commit-Position: refs/heads/master@{#622147}
12 files changed