Revert r143458 (which re-applies r143341 and r142979).

Revert r143458 (which re-applies r143341 and r142979).  This CL also includes
unit tests for DataReceived and DataReceived_ACK messaging.

Make ResourceHandlers that defer loading also be responsible for calling Resume
on their ResourceController.

What this does is avoid out-of-band calls to Resume the ResourceLoader, and
that means that an intermediate ResourceHandler (for example the
BufferedResourceHandler) will be able to implement ResourceController.

Consider the problematic scenerio that happens today:

1- The BufferedResourceHandler consumes response headers and buffers network
data, delaying notifications to its downstream ResourceHandler.
2- The BufferedResourceHandler decides if it is dealing with a download or
not, and optionally installs a DownloadResourceHandler as the downstream
handler.
3- The BufferedResourceHandler replays the OnResponseStarted and
OnReadCompleted events to push data to its downstream handler.
4- The downstream handler might decide to defer processing.
5- When the downstream handler wants to resume processing, it needs to
tell someone to Resume.

At step 5, the complicated thing we do to ourselves today is we make that
Resume step tell the ResourceLoader to resume instead of the
BufferedResourceHandler.

This causes problems for the BufferedResourceHandler as it may start receiving
more network events before it has finished flushing its existing buffers to its
downstream handler.

This patch is a step toward fixing the above problem. It makes all handlers
call Resume on their own controller when it is time to resume. A subsequent
patch will leverage this to cleanup and simplify the BufferedResourceHandler
as well as the overall pause/resume semantics of the ResourceLoader.

Other cleanup in this patch: The {Async,Sync,CrossSite}ResourceHandler
classes are now all constructed with an URLRequest. This avoids messy
code to call ResourceDispatcherHostImpl::GetURLRequest(). Since the
lifetime of ResourceHandlers is now bound to the lifetime of their
associated URLRequest, this is a safe and simple change to make. Other
ResourceHandlers, like the BufferedResourceHandler, were already holding
onto their associated URLRequest.

R=jam@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=143702

[darin (slow to review), 2012-06-22 19:10:40]

Take a look at the delta between patchset 1 and patchset 2.  Patchset 1 is the
combination of r143341 and r142979.  Patchset 2 includes the "fix" plus unit
tests.  One of the unit tests you already reviewed here: 
http://codereview.chromium.org/10612002/

[jam, 2012-06-22 19:54:42]

lgtm

[darin (slow to review), 2012-06-22 19:56:03]

https://chromiumcodereview.appspot.com/10644011/diff/12017/content/browser/re...
File content/browser/renderer_host/resource_dispatcher_host_impl.cc (right):

https://chromiumcodereview.appspot.com/10644011/diff/12017/content/browser/re...
content/browser/renderer_host/resource_dispatcher_host_impl.cc:1010:
scoped_ptr<ResourceHandler> handler;
btw, the point of this code move is to just ensure that the
ResourceRequestInfoImpl has been associated with the URLRequest before we build
the ResourceHandlers.  it enables the AsyncResourceHandler constructor to reach
out and modify the ResourceRequestInfoImpl.

[Vitaly Buka (NO REVIEWS), 2012-07-11 20:38:03]

What is the reason to revert?

On 2012/06/22 19:56:03, darin wrote:
>
https://chromiumcodereview.appspot.com/10644011/diff/12017/content/browser/re...
> File content/browser/renderer_host/resource_dispatcher_host_impl.cc (right):
> 
>
https://chromiumcodereview.appspot.com/10644011/diff/12017/content/browser/re...
> content/browser/renderer_host/resource_dispatcher_host_impl.cc:1010:
> scoped_ptr<ResourceHandler> handler;
> btw, the point of this code move is to just ensure that the
> ResourceRequestInfoImpl has been associated with the URLRequest before we
build
> the ResourceHandlers.  it enables the AsyncResourceHandler constructor to
reach
> out and modify the ResourceRequestInfoImpl.

[darin (slow to review), 2012-07-11 20:42:57]

On 2012/07/11 20:38:03, Vitaly Buka wrote:
> What is the reason to revert?

This is a revert of a revert.