Same also applies to network::mojom::URLLoaderClient

I'm going to take this one.  I think I need something like this to fully fix  bug 882425 .  I'm going to pursue the DataPipe approach.

I looked at this a bit and I'm not sure I want to block  bug 882425  on it now.  In particular, its not clear to me what depends on the metadata all being available prior to the start of the body.  Making that load asynchronously may have a long tail of things to fix.  It also may also require sequential loading such that it does not enable the asynchronous behavior I'd like for  bug 882425 .

What I was looking to do was something like:

 * Change URLLoaderClient::OnReceivedCachedMetadata() into separate start/complete methods.  The start method provides the pipe and the complete method signals the successful completion of the metadata read.
 * The metadata start method may get called at the same time as OnStartLoadingResponseBody().  So the metadata and body can start reading in parallel.

But I think there is some complexity here because it runs the risk of the cached metadata pipe not being drained and resulting in the body being available first.  Or I could block completing the response body pipe until the cached metadata is fully loaded, but if the loader does not drain the metadata pipe then the whole thing could stall.

This is probably solvable, but I'd like to disconnect the complexity from  bug 882425  for now.

Let me try to see if this worth doing. I've been investigating SW performance on a site and I noticed that reading side data seems a bottle neck.

Fyi, we also have: bug 867848 for regular loading cases.