Always create a proxy for cross-process navigations.

Previously, if a frame F navigated cross-process from a.com to b.com,
and this was the first navigation to the b.com process in that
BrowsingInstance, we did the following:

1. Create proxies for all frames in FrameTrees on F's opener chain.

2. Create proxies for all frames in F's FrameTree, except for F and
its subtree.

3.  If F is a main frame:

  3a. Create a new active RenderView, which also creates the main
  frame, already swapped into the tree even though it's still pending
  and may never commit.

  Otherwise, if F is a cross-process subframe:

  3b. send a CreateFrame IPC, referencing the parent proxy, which
  should've been created in step 2.

This flow breaks down if, while the navigation in F is still pending,
other frames in the same BrowsingInstance also navigate to b.com and
then try to interact with F (where the current RFH is still at a.com).

For example, if F is a main frame, and a subframe of F at a.com
navigates to b.com, the subframe won't find the parent proxy for F,
because we didn't create one in step 3a.  This crashes on
CHECK(parent) in CreateFrame().

Furthermore, if the subframe commits first, it should be able to
reference F.  For example, if the subframe sends a postMessage to F,
that should go to F's proxy in b.com, which should forward it to F's
current RenderFrame, which is still in a.com.  So there should be a
proxy created for F in step 3a.  This is especially important if F
never commits.

The same kind of race is possible with openers: a frame at C might
window.open() a new tab, then the opener frame starts a cross-process
navigation to D, then the opened tab also starts a cross-process
navigation to D.  If the opener's navigation never succeeds but the
opened tab's does, the opened tab at D should still be able to
communicate with its old opener at C.

To address these races, this CL changes step 2, so that when a frame
navigates cross-process, we pre-create a proxy for that frame
in the new SiteInstance for cases where other frames might also
navigate to the same new SiteInstance and script this frame.  This
switches the frame creation/navigation in steps 3a or 3b to instead
follow the remote-to-local navigation path, i.e., sending the
CreateFrame IPC and using the existing-proxy (CreateProvisional) flow.

As part of the fix, RenderViewCreated is changed to also be generated
for RVHs created for provisional main frame navigations, and
RenderViewHostImpl::GetMainFrame() will also return pending main frame
RFH if it exists.  This keeps the embedder's assumptions about
RenderViewHost valid.  Longer-term, these APIs should be deprecated
and migrated to use RenderFrameCreated.  This followup work will be
tracked in issue 763548.

Bug: 756790, 626802, 591478, 760403
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I6b85d135ec1e507110a51c9fe1b2a05754633a50
Reviewed-on: https://chromium-review.googlesource.com/636786
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Jialiu Lin <jialiul@chromium.org>
Reviewed-by: Charlie Reis (slow) <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501081}
23 files changed