Making Google Translate compatible with |request_initiator_site_lock|.

Google Translate executes its scripts inside "isolated worlds".  This is
quite similar to how extension content scripts execute and has a
consequence of using |request_initiator| set to the origin of the
isolated world (rather than to the origin of the page where the script
was injected).  This is problematic for 2 reasons:
1. It leads to renderer kills, when an AppCache verifies
   |request_initiator| using CPSPI::CanAccessDataForOrigin.
2. It leads to incompatibility between |request_initiator| and
   |request_initiator_site_lock| which can also cause wrong/harsh
   security decisions (e.g. CORB blocking of otherwise benign requests).

This CL addresses the problems above, by making sure that requests
initiated by the Translate's "isolated worls" will use a separate
URLLoaderFactory.
- For injecting and selecting the factory on the renderer side, the same
  mechanism is used as for extension content scripts (i.e.
  URLLoaderFactoryBundleInfo::initiator_specific_factory_infos is
  populated for the origin associated with the "isolated world").
- For simplicity and to avoid races, the separate URLLoaderFactory is
  sent from the browser to the renderer process in the same, single IPC
  that triggers script injection into an isolated world (i.e. in
  translate::mojom::Page::Translate method).

As a side effect, this CL also causes Translate's requests to go
directly to the NetworkService (rather than to the AppCache's
AppCacheSubresourceURLFactory).  This seems desirable.

Bug: 925457
Change-Id: I6227f9d8a43329510f4fae37ab9429c9dbf59f48
Reviewed-on: https://chromium-review.googlesource.com/c/1441277
Commit-Queue: Ɓukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633779}
18 files changed