OpenURL post data handling.

Passing ResourceRequestBody via FrameHostMsg_OpenURL_Params.

This CL adds support for passing ResourceRequestBody (i.e. POST data)
inside the payload of FrameHostMsg_OpenURL IPC message.

This CL adds |uses_post| and |resource_request_body| to
FrameHostMsg_OpenURL_Params and plumbs through these 2 values into
OpenURLParams passed to //content embedder.

This CL wraps-up the work started in 2 earlier CLs:

- https://crrev.com/2038813003 (Making ResourceRequestBody part of
  //content's public API.)

- https://crrev.com/2038233002 (Using ResourceRequestBody as the type of
  HTTP body outside of //content)

After this CL scenarios and tests that requires passing of POST data
via OpenURL code path should start working:

- HTTP POST requests where decidePolicyForNavigation tells that the
  request should be handled by the //content embedder.  This scenario
  is covered by a new CrossSiteTransferTest.PostViaOpenUrlMsg content
  browser test added in this CL.

- HTTP POST requests handled by RenderFrame::navigate (i.e. form
  submissions targeting remote frame).  This scenario is covered
  by a layout test added in a recent CL:
  http/tests/navigation/form-targets-cross-site-frame-post.html

BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/bb2101b8d45775fef16a0ce4af1ae71f35749e76
Cr-Commit-Position: refs/heads/master@{#400442}

[Łukasz Anforowicz, 2016-05-20 23:18:29]

Description was changed from

==========
OpenURL post data handling.

BUG=344348
==========

to

==========
OpenURL post data handling.

BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[Łukasz Anforowicz, 2016-05-20 23:24:21]

lukasza@chromium.org changed reviewers:
+ creis@chromium.org

[Łukasz Anforowicz, 2016-05-20 23:24:22]

Charlie, this CL is not ready for a real review, but I had 2 questions below -
could you please take a look?

https://codereview.chromium.org/2004653002/diff/20001/content/browser/cross_s...
File content/browser/cross_site_transfer_browsertest.cc (right):

https://codereview.chromium.org/2004653002/diff/20001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:426:
IN_PROC_BROWSER_TEST_F(CrossSiteTransferTest, PostViaOpenUrlMsg) {
Is this a reasonable location for this new test?  Note that there is nothing
"cross-site" about the test - the main feature of the test is that it submits a
method=POST form while browser_handles_all_top_level_requests is set to true.

Note - maybe the need for this test will go away if fix for
https://crbug.com/585284 will start exercising OpenURL path for remote frames
(i.e. even if browser_handles_all_top_level_requests is not set to true).

https://codereview.chromium.org/2004653002/diff/20001/content/browser/frame_h...
File content/browser/frame_host/navigator_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/20001/content/browser/frame_h...
content/browser/frame_host/navigator_impl.cc:735: //   of //content).
WDYT?  Does option #1 (exposing a minimal ResourceRequestBody out of //content's
public API) make sense?  I am not sure what is Chromium's stance toward classes
that only have an "impl" pointer.

Is there some other option here that I am missing?

[Łukasz Anforowicz, 2016-05-23 13:43:18]

lukasza@chromium.org changed reviewers:
- creis@chromium.org

[Łukasz Anforowicz, 2016-05-23 13:43:18]

Charlie, feel free to ignore this CL for now - I think I've found my answer
after sleeping on my questions for a little while.  I'll move you from reviewers
to the CC line for now.

https://codereview.chromium.org/2004653002/diff/20001/content/browser/frame_h...
File content/browser/frame_host/navigator_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/20001/content/browser/frame_h...
content/browser/frame_host/navigator_impl.cc:735: //   of //content).
On 2016/05/20 23:24:22, Łukasz Anforowicz wrote:
> WDYT?  Does option #1 (exposing a minimal ResourceRequestBody out of
//content's
> public API) make sense?  I am not sure what is Chromium's stance toward
classes
> that only have an "impl" pointer.
>
Actually, feel free to ignore the question - after sleeping on the problem, I
now see that I should just do this in a similar way to what //content already
does for RFH/RFHI:

//content/public/common/resource_request_body.h (new file):

class CONTENT_EXPORT ResourceRequestBody
    : public base::RefCountedThreadSafe<ResourceRequestBody> {
 public:
  scoped_refptr<ResourceRequestBody> CreateFromBytes(
      const std::vector<char> bytes);

  // no public API, except CreateFromBytes + ref-counting.

 protected:
  ResourceRequestBody();

 private:
  friend class base::RefCountedThreadSafe<ResourceRequestBody>;
  DISALLOW_COPY_AND_ASSIGN(ResourceRequestBody);  
} 

//content/common/resource_request_body_impl.h (renamed from the old
//content/common/resource_request_body.h):
 
class CONTENT_EXPORT ResourceRequestBodyImpl
    : public ResourceRequestBody,
      public base::SupportsUserData {
 // All the old declarations and members...
}

[Łukasz Anforowicz, 2016-06-08 23:38:00]

Description was changed from

==========
OpenURL post data handling.

BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Passing ResourceRequestBody via FrameHostMsg_OpenURL_Params.

This CL adds support for passing ResourceRequestBody (i.e. POST data)
inside the payload of FrameHostMsg_OpenURL IPC message.

This CL adds |uses_post| and |resource_request_body| to
FrameHostMsg_OpenURL_Params and plumbs through these 2 values into
OpenURLParams passed to //content embedder.


This CL wraps-up the work started in 2 earlier CLs:

- https://crrev.com/2038813003 (Making ResourceRequestBody part of
  //content's public API.)

- https://crrev.com/2038233002 (Using ResourceRequestBody as the type of
  HTTP body outside of //content)


After this CL scenarios and tests that requires passing of POST data
via OpenURL code path should start working:

- HTTP POST requests where decidePolicyForNavigation tells that the
  request should be handled by the //content embedder.  This scenario
  is covered by a new CrossSiteTransferTest.PostViaOpenUrlMsg content
  browser test added in this CL.

- HTTP POST requests handled by RenderFrame::navigate (i.e. form
  submissions targeting remote frame).  This scenario is covered
  by a layout test added in a recent CL:
  http/tests/navigation/form-targets-cross-site-frame-post.html


BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[Łukasz Anforowicz, 2016-06-09 16:26:12]

lukasza@chromium.org changed reviewers:
+ creis@chromium.org

[Łukasz Anforowicz, 2016-06-09 16:26:13]

Charlie, can you take a look please?

https://codereview.chromium.org/2004653002/diff/60001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/FlagExpectations/site-per-process (right):

https://codereview.chromium.org/2004653002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/FlagExpectations/site-per-process:12: #
http/tests/navigation/form-targets-cross-site-frame-get.html [ Pass ]
The linux_site_isolation tryjob failure is expected at this point and should go
away before landing - the test I am enabling should start passing once I rebase
on top of https://codereview.chromium.org/1999573003.

[Charlie Reis, 2016-06-09 22:59:42]

Exciting!  Looks mostly good, though I'm a bit unclear how much is left to fix
https://crbug.com/585284.  We seem to be passing the POST data up through
RenderFrameProxy{Impl}, so is there a reason that test still isn't passing?

A few other minor nits below.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
File content/browser/cross_site_transfer_browsertest.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:426:
IN_PROC_BROWSER_TEST_F(CrossSiteTransferTest, PostViaOpenUrlMsg) {
I think this might not belong in CrossSiteTransferTest, which is more about
transfers (i.e., cross-process navigations that switch process after the network
request is made, just before commit time).

I'd suggest either render_frame_host_manager_browsertest.cc or
navigation_controller_impl_browsertest.cc, since this is more about
cross-process navigations that switch processes before the network request is
made.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:445: // Verify that we
arrived at the expected, redirected location.
What do you mean by redirected?  I don't see any redirects in the test, so
perhaps you mean "at the expected location, via OpenURL"?

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:449: // Verify that POST body
was correctly passed to the server.
nit: ...and ended up in the body of the page.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:267:
params.resource_request_body);
Naively, I would expect this to fix https://crbug.com/585284 as well, but it
looks like we're still failing form-targets-cross-site-frame.html.  I take it
something else is needed?

[Łukasz Anforowicz, 2016-06-10 19:53:52]

Charlie, can you take another look please?

On 2016/06/09 22:59:42, Charlie Reis wrote:
> Exciting!  Looks mostly good, though I'm a bit unclear how much is left to fix
> https://crbug.com/585284.  We seem to be passing the POST data up through
> RenderFrameProxy{Impl}, so is there a reason that test still isn't passing?

The test should pass once the other part of the fix for 585284 lands
(https://codereview.chromium.org/1999573003 is almost all the way through CQ).

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
File content/browser/cross_site_transfer_browsertest.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:426:
IN_PROC_BROWSER_TEST_F(CrossSiteTransferTest, PostViaOpenUrlMsg) {
On 2016/06/09 22:59:42, Charlie Reis wrote:
> I think this might not belong in CrossSiteTransferTest, which is more about
> transfers (i.e., cross-process navigations that switch process after the
network
> request is made, just before commit time).
> 
> I'd suggest either render_frame_host_manager_browsertest.cc or
> navigation_controller_impl_browsertest.cc, since this is more about
> cross-process navigations that switch processes before the network request is
> made.

Done.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:445: // Verify that we
arrived at the expected, redirected location.
On 2016/06/09 22:59:42, Charlie Reis wrote:
> What do you mean by redirected?  I don't see any redirects in the test, so
> perhaps you mean "at the expected location, via OpenURL"?

My fault - I've incorrectly copy&paste parts of this test from somewhere else
(this included this not quite correct comment.  Done.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/cross_s...
content/browser/cross_site_transfer_browsertest.cc:449: // Verify that POST body
was correctly passed to the server.
On 2016/06/09 22:59:42, Charlie Reis wrote:
> nit: ...and ended up in the body of the page.

Done.

https://codereview.chromium.org/2004653002/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:267:
params.resource_request_body);
On 2016/06/09 22:59:42, Charlie Reis wrote:
> Naively, I would expect this to fix https://crbug.com/585284 as well, but it
> looks like we're still failing form-targets-cross-site-frame.html.  I take it
> something else is needed?

Sorry for the confusion.  The CL under view fixes POST submissions for
https://crbug.com/585284 as well, but the full fix requires *both*: 1) the CL
under review and 2) handling form submissions targeting remote frames (currently
in CQ: http://codereview.chromium.org/1999573003).

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
content/renderer/render_frame_impl.cc:4827: // for examples of how to send the
httpBody data.
One extra change here (one that wasn't solicited by CR feedback): removing
no-longer-applicable comment above.

[Łukasz Anforowicz, 2016-06-10 20:00:48]

lukasza@chromium.org changed reviewers:
+ nasko@chromium.org

[Łukasz Anforowicz, 2016-06-10 20:00:49]

Nasko, can you do an OWNERS review for content/common/frame_messages.h?

https://codereview.chromium.org/2004653002/diff/100001/content/common/frame_m...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/2004653002/diff/100001/content/common/frame_m...
content/common/frame_messages.h:453: resource_request_body)
Note that this is not the first time when we send ResourceRequestBody back into
the renderer process (i.e. we already do it in
content::ResourceRequest::request_body embedded in
ResourceHostMsg_RequestResource and a few other IPC messages).

This *is* the first time when ResourceRequestBody is passed above //content
layer, into the embedder.  OTOH, above //content ResourceRequestBody is opaque
[1], so I think we shouldn't be getting any extra exposure here.

[1] e.g. see the class comment in content/public/common/resource_request_body.h
in https://codereview.chromium.org/2038813003/patch/40001/50059

[nasko, 2016-06-10 20:22:29]

IPC l-t-g-m. Will stamp it for real once creis@ has, as we are both content/
owners.

https://codereview.chromium.org/2004653002/diff/100001/content/common/frame_m...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/2004653002/diff/100001/content/common/frame_m...
content/common/frame_messages.h:453: resource_request_body)
On 2016/06/10 20:00:49, Łukasz Anforowicz wrote:
> Note that this is not the first time when we send ResourceRequestBody back
into
> the renderer process (i.e. we already do it in
> content::ResourceRequest::request_body embedded in
> ResourceHostMsg_RequestResource and a few other IPC messages).
> 
> This *is* the first time when ResourceRequestBody is passed above //content
> layer, into the embedder.  OTOH, above //content ResourceRequestBody is opaque
> [1], so I think we shouldn't be getting any extra exposure here.
> 
> [1] e.g. see the class comment in
content/public/common/resource_request_body.h
> in https://codereview.chromium.org/2038813003/patch/40001/50059

FrameHostMsg_OpenURL_Params cannot be seen outside of content/, so I don't think
adding the Impl to this IPC message is a problem. The handler of the IPC that
sends the results of it outside of content/ should be the one ensuring we only
expose the public interface.

[Charlie Reis, 2016-06-10 21:14:18]

Thanks!  LGTM, once the test expectations are updated.

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
content/renderer/render_frame_impl.cc:4827: // for examples of how to send the
httpBody data.
On 2016/06/10 19:53:52, Łukasz Anforowicz wrote:
> One extra change here (one that wasn't solicited by CR feedback): removing
> no-longer-applicable comment above.

Good catch!  That reminded me to do a search for 101395, and I found another one
in ChromeContentRendererClient::ShouldFork.  That case should be safe to remove,
but I'd be ok with doing that in a followup CL if you'd prefer (to avoid any
risk).

That also reminded me of comment 15 on https://crbug.com/101395, which was
actually a bit scary.  Thankfully, that signin code went away in
https://codereview.chromium.org/964553002.  Hooray!

[Łukasz Anforowicz, 2016-06-10 23:11:53]

On 2016/06/10 21:14:18, Charlie Reis wrote:
> Thanks!  LGTM, once the test expectations are updated.
> 
>
https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
> File content/renderer/render_frame_impl.cc (right):
> 
>
https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
> content/renderer/render_frame_impl.cc:4827: // for examples of how to send the
> httpBody data.
> On 2016/06/10 19:53:52, Łukasz Anforowicz wrote:
> > One extra change here (one that wasn't solicited by CR feedback): removing
> > no-longer-applicable comment above.
> 
> Good catch!  That reminded me to do a search for 101395, and I found another
one
> in ChromeContentRendererClient::ShouldFork.  That case should be safe to
remove,
> but I'd be ok with doing that in a followup CL if you'd prefer (to avoid any
> risk).

Yes - I'd like to do this in a separate CL.  I am guessing (arm-chair analysis
FTW?... :-/) that without undoing ChromeContentRendererClient::ShouldFork
changes we won't hit the http-or-https-only DCHECK in LoadURLWithParams.  So -
I'd like to come up with a test that tickles this DCHECK in the same CL that
cleans up ShouldFork.
> 
> That also reminded me of comment 15 on https://crbug.com/101395, which was
> actually a bit scary.  Thankfully, that signin code went away in
> https://codereview.chromium.org/964553002.  Hooray!

[nasko, 2016-06-11 03:41:12]

IPC LGTM

[dcheng, 2016-06-12 05:28:59]

dcheng@chromium.org changed reviewers:
+ dcheng@chromium.org

[dcheng, 2016-06-12 05:29:00]

https://codereview.chromium.org/2004653002/diff/100001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/100001/content/renderer/rende...
content/renderer/render_frame_impl.cc:2924:
GetRequestBodyForWebURLRequest(request), referrer, policy,
Two questions:
1) Is there another CL that changes GetRequestBodyForWebURLRequest()?
GetRequestBodyForWebURLRequest() will currently DCHECK() if the request is a GET
or HEAD request.
2) DO we need to pass both IsHttpPost(Request) and the request body? Can we
infer POST based on request body being non-null?

[Łukasz Anforowicz, 2016-06-13 18:26:23]

Daniel, please see my reply below.

https://codereview.chromium.org/2004653002/diff/100001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/100001/content/renderer/rende...
content/renderer/render_frame_impl.cc:2924:
GetRequestBodyForWebURLRequest(request), referrer, policy,
On 2016/06/12 05:29:00, dcheng wrote:
> Two questions:
> 1) Is there another CL that changes GetRequestBodyForWebURLRequest()?
> GetRequestBodyForWebURLRequest() will currently DCHECK() if the request is a
GET
> or HEAD request.

There is no pending CL related to the current one + modifying
GetRequestBodyForWebURLRequest.

I think this is fine, because the DCHECK will fire only if *both* conditions are
bet:

A) The request is a GET or HEAD request

B) The request has a body.

That is - we return before the DCHECK if |request.httpBody().isNull()|.

> 2) DO we need to pass both IsHttpPost(Request) and the request body? Can we
> infer POST based on request body being non-null?

Yeah, I wondered about this.  I think having 2 separate values is better
because:

1. Separation is consistent with 

1.1. chrome::NavigateParams (which has a |bool uses_post| field).

1.2. blink::ResourceRequest and net::URLRequest (which both have a separate
method and body fields).  Granted - these deal not only with page/frame
navigations (e.g. they also deal with other kinds network requests - for example
XHRs can use PUT or other more esoteric HTTP methods), but I think the
consistency is still desirable.

2. IMO separation is desirable for maintainability, because these truly are
separate things - i.e. presence of request body implies HTTP POST method in page
navigations *today*, but this implication might not hold in the future (i.e. if
body will start making sense for non-HTTP navigations, of if we decide to start
supporting PUT for page navigations;  I understand that these examples are
hypothetical, but I hopefully they illustrate why mxing of method+body into one
field might be undesirable / might introduce unnecessary assumptions into code).

[Łukasz Anforowicz, 2016-06-15 21:32:38]

On 2016/06/10 21:14:18, Charlie Reis (OOO til June 18) wrote:
> Thanks!  LGTM, once the test expectations are updated.

I've rebased + updated the test expectations in the latest patchset.

[Charlie Reis, 2016-06-16 22:27:40]

Thanks, updated expectations LGTM.

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
content/renderer/render_frame_impl.cc:4827: // for examples of how to send the
httpBody data.
On 2016/06/10 23:11:53, Łukasz Anforowicz wrote:
> On 2016/06/10 21:14:18, Charlie Reis wrote:
> > Thanks!  LGTM, once the test expectations are updated.
> > 
> >
>
https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
> > File content/renderer/render_frame_impl.cc (right):
> > 
> >
>
https://codereview.chromium.org/2004653002/diff/60001/content/renderer/render...
> > content/renderer/render_frame_impl.cc:4827: // for examples of how to send
the
> > httpBody data.
> > On 2016/06/10 19:53:52, Łukasz Anforowicz wrote:
> > > One extra change here (one that wasn't solicited by CR feedback): removing
> > > no-longer-applicable comment above.
> > 
> > Good catch!  That reminded me to do a search for 101395, and I found another
> one
> > in ChromeContentRendererClient::ShouldFork.  That case should be safe to
> remove,
> > but I'd be ok with doing that in a followup CL if you'd prefer (to avoid any
> > risk).
> 
> Yes - I'd like to do this in a separate CL.  I am guessing (arm-chair analysis
> FTW?... :-/) that without undoing ChromeContentRendererClient::ShouldFork
> changes we won't hit the http-or-https-only DCHECK in LoadURLWithParams.  So -
> I'd like to come up with a test that tickles this DCHECK in the same CL that
> cleans up ShouldFork.

SGTM.

> > 
> > That also reminded me of comment 15 on https://crbug.com/101395, which was
> > actually a bit scary.  Thankfully, that signin code went away in
> > https://codereview.chromium.org/964553002.  Hooray!

[Łukasz Anforowicz, 2016-06-17 14:46:04]

The CQ bit was checked by lukasza@chromium.org

[Łukasz Anforowicz, 2016-06-17 14:46:04]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2004653002/#ps160001
(title: "Rebasing...")

[commit-bot: I haz the power, 2016-06-17 14:46:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2004653002/160001

[commit-bot: I haz the power, 2016-06-17 16:52:39]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-06-17 16:54:31]

Description was changed from

==========
Passing ResourceRequestBody via FrameHostMsg_OpenURL_Params.

This CL adds support for passing ResourceRequestBody (i.e. POST data)
inside the payload of FrameHostMsg_OpenURL IPC message.

This CL adds |uses_post| and |resource_request_body| to
FrameHostMsg_OpenURL_Params and plumbs through these 2 values into
OpenURLParams passed to //content embedder.


This CL wraps-up the work started in 2 earlier CLs:

- https://crrev.com/2038813003 (Making ResourceRequestBody part of
  //content's public API.)

- https://crrev.com/2038233002 (Using ResourceRequestBody as the type of
  HTTP body outside of //content)


After this CL scenarios and tests that requires passing of POST data
via OpenURL code path should start working:

- HTTP POST requests where decidePolicyForNavigation tells that the
  request should be handled by the //content embedder.  This scenario
  is covered by a new CrossSiteTransferTest.PostViaOpenUrlMsg content
  browser test added in this CL.

- HTTP POST requests handled by RenderFrame::navigate (i.e. form
  submissions targeting remote frame).  This scenario is covered
  by a layout test added in a recent CL:
  http/tests/navigation/form-targets-cross-site-frame-post.html


BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Passing ResourceRequestBody via FrameHostMsg_OpenURL_Params.

This CL adds support for passing ResourceRequestBody (i.e. POST data)
inside the payload of FrameHostMsg_OpenURL IPC message.

This CL adds |uses_post| and |resource_request_body| to
FrameHostMsg_OpenURL_Params and plumbs through these 2 values into
OpenURLParams passed to //content embedder.

This CL wraps-up the work started in 2 earlier CLs:

- https://crrev.com/2038813003 (Making ResourceRequestBody part of
  //content's public API.)

- https://crrev.com/2038233002 (Using ResourceRequestBody as the type of
  HTTP body outside of //content)

After this CL scenarios and tests that requires passing of POST data
via OpenURL code path should start working:

- HTTP POST requests where decidePolicyForNavigation tells that the
  request should be handled by the //content embedder.  This scenario
  is covered by a new CrossSiteTransferTest.PostViaOpenUrlMsg content
  browser test added in this CL.

- HTTP POST requests handled by RenderFrame::navigate (i.e. form
  submissions targeting remote frame).  This scenario is covered
  by a layout test added in a recent CL:
  http/tests/navigation/form-targets-cross-site-frame-post.html

BUG=344348
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/bb2101b8d45775fef16a0ce4af1ae71f35749e76
Cr-Commit-Position: refs/heads/master@{#400442}
==========

[commit-bot: I haz the power, 2016-06-17 16:54:32]

Patchset 9 (id:??) landed as
https://crrev.com/bb2101b8d45775fef16a0ce4af1ae71f35749e76
Cr-Commit-Position: refs/heads/master@{#400442}

[oystein (OOO til 10th of July), 2016-06-21 12:51:23]

A revert of this CL (patchset #9 id:160001) has been created in
https://codereview.chromium.org/2088793002/ by oysteine@chromium.org.

The reason for reverting is: Reverting due to
https://bugs.chromium.org/p/chromium/issues/detail?id=621473.

[oystein (OOO til 10th of July), 2016-06-21 12:53:06]

On 2016/06/21 12:51:23, Oystein wrote:
> A revert of this CL (patchset #9 id:160001) has been created in
> https://codereview.chromium.org/2088793002/ by mailto:oysteine@chromium.org.
> 
> The reason for reverting is: Reverting due to
> https://bugs.chromium.org/p/chromium/issues/detail?id=621473.

Oops, please ignore this sorry, wrong CL.