Use FrameTreeNode ID as frameId in extension APIs

Use FrameTreeNode IDs instead of RenderFrame routing IDs as "frame id"
in the extension APIs (webNavigation, webRequest, extension messaging)
because FTN IDs are globally unique, and RFH IDs are not.

This extends the public content API with:
- RenderFrameHost::FromFrameTreeNodeId
- RenderFrameHost::GetFrameTreeNodeId
- WebContents::FindFrameByFrameTreeNodeId

The extension APIs are modified as follows:
- webRequest:
  * Frame IDs may be unavailable after frame removal (crbug.com/572930).
  * Blocking webRequest handlers may be slower than before due to an
    extra IO->UI->IO hop to determine the frameId (but this happens only
    once per frame load).
- webNavigation:
  * processId is no longer required in chrome.webNavigation.getFrame,
    but marked as optional (deprecated) to make sure that the API is
    backwards-compatible.
  * frameId is constant across navigations.
- Extension messaging (chrome.runtime.connect and friends):
  * Small change for extension developers in the following scenario:
    1. Open port to tab.
    2. Accept the port by listening to onConnect *in a child frame*.
    3. Unload the document in the frame.
    Old behavior: onDisconnect was not triggered in the background until
                  the tab was reloaded or closed.
    New behavior: onDisconnect is called.
  * Extension messaging works correctly in out-of-process frames.
  * Move port lifetime management from renderer to browser.
  * Tie port lifetime to frames instead of processes.
  * Only notify frames in renderers if they have accepted the port.
  * Remove obsolete work-around for crbug.com/520303.
  * Unify open/close/postMessage logic in ChromeExtensionMessageFilter
    (crbug.com/394383#c7)
- The extension frameId logic is no longer scattered over several files,
  but resides in a single class (ExtensionApiFrameIdMap).
- IDs are now guaranteed to be -1 or higher (before this, -2 was
  occasionally seen).

Depends on https://codereview.chromium.org/1413853005/

BUG=432875
TEST=browser_tests --gtest_filter=\
ExtensionWebRequestApiTest.*:\
WebNavigationApiTest.*:\
ExtensionApiTest.Messaging*:\
ExternallyConnectableMessagingTest.*:\
ExternallyConnectableMessagingWithTlsChannelIdTest.*

Review URL: https://codereview.chromium.org/1413543005

Cr-Commit-Position: refs/heads/master@{#367914}

1 files changed, 10 insertions, 0 deletions

diff --git a/extensions/renderer/resources/messaging.js b/extensions/renderer/resources/messaging.js
index 5a7ec1e..a15497d 100644
--- a/extensions/renderer/resources/messaging.js
+++ b/extensions/renderer/resources/messaging.js
@@ -76,6 +76,16 @@
       this.onDestroy_();
     privates(this.onDisconnect).impl.destroy_();
     privates(this.onMessage).impl.destroy_();
+    // TODO(robwu): Remove port lifetime management because it is completely
+    // handled in the browser. The renderer's only roles are
+    // 1) rejecting ports so that the browser knows that the renderer is not
+    //    interested in the port (this is merely an optimization)
+    // 2) acknowledging port creations, so that the browser knows that the port
+    //    was successfully created (from the perspective of the extension), but
+    //    then closed for some non-fatal reason.
+    // 3) notifying the browser of explicit port closure via .disconnect().
+    // In other cases (navigations), the browser automatically cleans up the
+    //    port.
     messagingNatives.PortRelease(this.portId_);
     delete ports[this.portId_];
   };