Introduce content-side Feature Policy object and maintain in parallel with renderer policy.

content/browser/frame_host/frame_tree_node.h

Index: content/browser/frame_host/frame_tree_node.h
diff --git a/content/browser/frame_host/frame_tree_node.h b/content/browser/frame_host/frame_tree_node.h
index 2004107fe107d352a164d7bae5701d653cc734d7..64126c1e7aa696c6eb835b8216e7f7b70751d543 100644
--- a/content/browser/frame_host/frame_tree_node.h
+++ b/content/browser/frame_host/frame_tree_node.h
@@ -25,6 +25,7 @@
 
 namespace content {
 
+class FeaturePolicy;
 class FrameTree;
 class NavigationRequest;
 class Navigator;
@@ -352,6 +353,8 @@ class CONTENT_EXPORT FrameTreeNode {
   // proxies for this frame.
   FrameReplicationState replication_state_;
 
+  std::unique_ptr<FeaturePolicy> feature_policy_;

[pfeldman, 2017/02/03 18:04:26]

I'd talk to someone from the site isolation team on whether this is the right
place for it.

[iclelland, 2017/02/03 19:26:37]

Thanks -- alexmos, do you have any idea whether this is right? The policy
*header* is already being replicated between frames (on the replication_state_
member); this is for the independently-constructed policy in the browser
process, which should exist regardless of site-isolation.

It may make more sense to put this on the render_frame_host, for instance, as it
is the browser's view of the policy which should exist in the renderer. (We plan
to query this policy in the browser process when that's the right place to make
decisions, like for permission-backed features)

[alexmos, 2017/02/03 22:37:16]

I think it might make more sense to put this on the RenderFrameHost. The main
issue is this will be incorrect if you will ever need to check feature policy on
a non-current RFH (i.e., pending RFH [for cross-process navigation that hasn't
yet committed] or pending delete RFH [running unload handler after another RFH
has committed a navigation and became current for this FTN]).  We've had this
issue with URLs and origins (see issues 590034, 590035, 663740), and ended up
storing both of those on RFHI. (The origin is still also kept in the FRS for
replication, but it should be avoided for origin checks unless you really know
what you're doing).  Seems like at least some of the features controlled by
feature policy could be utilized in unload handlers (right?), so you probably
have to worry about this.

[iclelland, 2017/02/06 18:32:33]

Thanks, Alex, I appreciate the insight. I've moved the actual policy to the
RFHI, with getter/setter methods. In the CL that actually starts using this from
the browser, I'll be adding a boolean IsFeatureEnabled() method to the RFH
public interface.

[alexmos, 2017/02/07 00:21:35]

Yes, that sounds good to me.

+
   // Track the pending sandbox flags for this frame.  When a parent frame
   // dynamically updates sandbox flags in the <iframe> element for a child
   // frame, these updated flags are stored here and are transferred into