Make DownloadResourceThrottle robust to ContinueDownload being called before

Make DownloadResourceThrottle robust to ContinueDownload being called before
WillStartRequest.

R=rdsmith@chromium.org
BUG=114853
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=124659

[Randy Smith (Not in Mondays), 2012-02-29 01:25:23]

So the code is correct, but it took me enough mapping out of the race to
convince myself of that that I could imagine improving the clarity some.

What you've effectively got here is a race between the first call to any of the
routines and the DownloadRequestLimiter response.  You need to delay any action
until after both of those events have occurred, and you're doing it by
explicitly tracking the intervals with booleans.  querying_limiter_ is true
while the request to the DRL is outstanding (construction to callback) and
request_deferred_ is true from the first call to a ResourceThrottle method (if
request to DRL outsanding) to the DownloadRequestLimiter callback. 
request_allowed_ is a different beast; it's just the result returned by the DRL.
 You're explicitly handling the two races differently; if the DRL comes back
before a RT method call, you just set request_allowed_, otherwise you also
message the controller.  

So a couple of suggestions that you're welcome to take or not as you wish;
probably you don't want to do all of them:
+ Put in a paragraph sketching out the race and actions.
+ Change the names of the variables to make it clear that the interval booleans
are different beasts from the DRL result.
+ Replace the interval booleans with an actual state enum with clear names to
indicate which state we're in (DRL_REQUEST_OUTSTANDING,
DRL_REQUEST_OUTSTANDING_DEFERRED, DOWNLOAD_BLOCKED, DOWNLOAD_ALLOWED?) and
transition between them as appropriate in the different routines.  

Having said all that, LGTM; it's up to you what you want to do.  It's possible
to figure out what's going on if you look closely.

[darin (slow to review), 2012-03-01 17:35:46]

I've restructured WillDownload and added a comment.  I think those small tweaks
should improve clarity quite a bit.  Now, it is a bit clearer that WillDownload
can't decide what to do while querying_limiter_ is true.

[Randy Smith (Not in Mondays), 2012-03-01 21:44:35]

LGTM.  Thank you.

[commit-bot: I haz the power, 2012-03-01 22:36:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/darin@chromium.org/9522006/7001

[commit-bot: I haz the power, 2012-03-02 03:49:59]

Try job failure for 9522006-7001 (retry) (retry) on win_rel for step "ui_tests".
It's a second try, previously, step "ui_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2012-03-02 05:20:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/darin@chromium.org/9522006/7001

[commit-bot: I haz the power, 2012-03-02 16:08:47]

Change committed as 124659