Move URLFetcherDelegate to net/ and split URLFetcher between net/ and content/

Move URLFetcherDelegate to net/ and split URLFetcher between net/ and content/

Temporarily make a shim content::URLFetcherDelegate class.  A future CL
will replace all instances of content::URLFetcherDelegate with
net::URLFetcherDelegate and remove that class.

Move most URLFetcher methods to net::URLFetcher, except for the static
methods (which will be handled in a future CL) and AssociateWithRenderView,
which is content-specific.

Replace all instances of content::URLFetcher* in the URLFetcherDelegate
callbacks with net::URLFetcher* (except for rlz, which required its own special hack).

BUG=118220
TEST=
TBR=mnissler@chromium.org,jhawkins@chromium.org,cpu@chromium.org,estade@chromium.org,sky@chromium.org,joth@chromium.org,satish@chromium.org

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=136514

[akalin, 2012-05-09 23:57:06]

+willchan for review

This CL touches a lot of files, but most of them are automatic
(content::URLFetcher* -> net::URLFetcher*, sort headers, update copyright).

The important files to look at are in net/ and content/.

[akalin, 2012-05-10 00:00:13]

+thakis FYI, since once this is ready to land, we'll have to also land an rlz
patch.

[akalin, 2012-05-10 00:01:26]

Also, I expect the Mac/Win trybots to fail because of rlz needing to be updated.
 I will build locally on those platforms instead (which I have to do anyway
since I have to prep the rlz patch).

[akalin, 2012-05-10 08:48:01]

On 2012/05/10 00:01:26, akalin wrote:
> Also, I expect the Mac/Win trybots to fail because of rlz needing to be
updated.
>  I will build locally on those platforms instead (which I have to do anyway
> since I have to prep the rlz patch).

Actually, I think I found a way to fix rlz without requiring changes to it. (See
end of url_fetcher_delegate.h)  It's a bit of a hack, but it'll be removed
quickly once the real fix for rlz lands.

[willchan no longer on Chromium, 2012-05-10 18:13:27]

lgtm

[akalin, 2012-05-10 19:59:57]

+jam for content/ and content/public/ OWNERS

TBRing all other owners since they're just mechanical changes

[darin (slow to review), 2012-05-10 23:33:33]

LGTM for src/content/ changes.

Maybe the net/url_request class could be better named?  How about
URLRequestProxy?  It reminds me of the relationship between IPC::Channel and
IPC::ChannelProxy.

[akalin, 2012-05-10 23:40:11]

On 2012/05/10 23:33:33, darin wrote:
> LGTM for src/content/ changes.
> 
> Maybe the net/url_request class could be better named?  How about
> URLRequestProxy?  It reminds me of the relationship between IPC::Channel and
> IPC::ChannelProxy.

Thanks, Darin!  I'll let you hash out the naming with Will.  I have no strong
opinions either way. :)

[commit-bot: I haz the power, 2012-05-10 23:43:48]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/akalin@chromium.org/10386063/2116

[commit-bot: I haz the power, 2012-05-11 00:09:29]

Try job failure for 10386063-2116 (retry) on android for steps "Compile, build".
It's a second try, previously, steps "Compile, build" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android&nu...

[commit-bot: I haz the power, 2012-05-11 04:09:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/akalin@chromium.org/10386063/2117

[commit-bot: I haz the power, 2012-05-11 05:32:27]

Change committed as 136514

[jam, 2012-05-11 22:18:38]

just to be clear, this interface in content that derives from an
interface/implementation in net is just temporarily right (per the email
discussion that we had about this)?

[akalin, 2012-05-11 22:23:35]

On 2012/05/11 22:18:38, John Abd-El-Malek wrote:
> just to be clear, this interface in content that derives from an
> interface/implementation in net is just temporarily right (per the email
> discussion that we had about this)?

Hmm.  I thought we agreed that content::URLFetcher would derive from
net::URLFetcher, but content::URLFetcherImpl and net::URLFetcherImpl would be
separate implementations that would forward to a URLFetcherCore?  Did I
misunderstand?

[willchan no longer on Chromium, 2012-05-11 22:29:05]

I think I said what Fred said, but the point was that the net::URLFetcher
interface would be dramatically simpler.

On Fri, May 11, 2012 at 3:23 PM, <akalin@chromium.org> wrote:

> On 2012/05/11 22:18:38, John Abd-El-Malek wrote:
>
>> just to be clear, this interface in content that derives from an
>> interface/implementation in net is just temporarily right (per the email
>> discussion that we had about this)?
>>
>
> Hmm.  I thought we agreed that content::URLFetcher would derive from
> net::URLFetcher, but content::URLFetcherImpl and net::URLFetcherImpl would
> be
> separate implementations that would forward to a URLFetcherCore?  Did I
> misunderstand?
>
>
http://codereview.chromium.**org/10386063/<http://codereview.chromium.org/103...
>