Refactor CreateOpenerProxies to support updates to frame openers.
Currently, CreateOpenerProxies assumes that (1) each opener chain can
be recursively traversed until hitting a node with no opener, and (2)
subframes can't have openers. Neither (1) nor (2) will hold once we
propagate frame opener updates (that happen via window.open) to the
browser process.
To address (1), this CL changes the recursive traversal in
CreateOpenerProxies to a BFS traversal that is resilient to potential
cycles on the opener chain. To address (2), openers are examined for
all nodes on a given FrameTree, rather than just for the root node.
If the opener graph contains cycles, some proxies created by
CreateOpenerProxies may not have their opener_routing_id available at
creation time. In a future CL, once opener update IPCs are
implemented, these proxies will need to set their openers in a second
pass (note that this is expected to be very rare, hence an extra IPC
should be ok). This CL prepares for this by adding logic to collect
nodes involved in cycles that will need this extra processing.
BUG=225940
Review URL: https://codereview.chromium.org/
1268153002
Cr-Commit-Position: refs/heads/master@{#342221}