Fix Data Saver test in Cronet

Fix Data Saver test in Cronet

Task posts in Data Saver logic were delaying initialization
unnecessarily in Cronet, and consequently, the first
request after initialization wasn't necessarily proxied.
This CL makes the initialization logic synchronous when
Data Saver's UI and IO task runners are on the same thread.

BUG=461910
Committed: https://crrev.com/0993cb9f8f775a7c4b40525c55785f389acde1a5
Cr-Commit-Position: refs/heads/master@{#330579}

[bengr, 2015-05-15 15:22:45]

bengr@chromium.org changed reviewers:
+ mmenke@chromium.org

[mmenke, 2015-05-15 15:37:46]

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:142:
"http://eivnwoeivnowenv.com/datareductionproxysuccess.txt",
Can we just use http://DomainThatDoesntResolve/ ?

https://codereview.chromium.org/1143503005/diff/1/components/data_reduction_p...
File
components/data_reduction_proxy/core/browser/data_reduction_proxy_io_data.cc
(right):

https://codereview.chromium.org/1143503005/diff/1/components/data_reduction_p...
components/data_reduction_proxy/core/browser/data_reduction_proxy_io_data.cc:169:
if (io_task_runner_->BelongsToCurrentThread()) {
In the DRP's unit tests...Are the threads the same or different?  If they're
different, should have a unit test where they're the same.  If they're the same,
should have a unit test where they're not.

[bengr, 2015-05-15 19:30:21]

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:142:
"http://eivnwoeivnowenv.com/datareductionproxysuccess.txt",
On 2015/05/15 15:37:46, mmenke wrote:
> Can we just use http://DomainThatDoesntResolve/ ?

That doesn't work, but http://DomainThatDoesnt.Resolve/ does. Not sure why.

https://codereview.chromium.org/1143503005/diff/1/components/data_reduction_p...
File
components/data_reduction_proxy/core/browser/data_reduction_proxy_io_data.cc
(right):

https://codereview.chromium.org/1143503005/diff/1/components/data_reduction_p...
components/data_reduction_proxy/core/browser/data_reduction_proxy_io_data.cc:169:
if (io_task_runner_->BelongsToCurrentThread()) {
On 2015/05/15 15:37:46, mmenke wrote:
> In the DRP's unit tests...Are the threads the same or different?  If they're
> different, should have a unit test where they're the same.  If they're the
same,
> should have a unit test where they're not.

They're on the same thread. Agreed that we should have test coverage for
multiple threads. Filed
https://code.google.com/p/chromium/issues/detail?id=488568.

[mmenke, 2015-05-15 19:32:31]

LGTM

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:142:
"http://eivnwoeivnowenv.com/datareductionproxysuccess.txt",
On 2015/05/15 19:30:21, bengr wrote:
> On 2015/05/15 15:37:46, mmenke wrote:
> > Can we just use http://DomainThatDoesntResolve/ ?
> 
> That doesn't work, but http://DomainThatDoesnt.Resolve/ does. Not sure why.

Hrm...Weird.  Wonder if it's a net issue or a DRP issue.

[bengr, 2015-05-15 19:36:25]

On 2015/05/15 19:32:31, mmenke wrote:
> LGTM
> 
>
https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
> File
>
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
> (right):
> 
>
https://codereview.chromium.org/1143503005/diff/1/components/cronet/android/t...
>
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:142:
> "http://eivnwoeivnowenv.com/datareductionproxysuccess.txt",
> On 2015/05/15 19:30:21, bengr wrote:
> > On 2015/05/15 15:37:46, mmenke wrote:
> > > Can we just use http://DomainThatDoesntResolve/ ?
> > 
> > That doesn't work, but http://DomainThatDoesnt.Resolve/ does. Not sure why.
> 
> Hrm...Weird.  Wonder if it's a net issue or a DRP issue.

DRP doesn't do anything with URLs, so I suspect net, possibly the java.

[bengr, 2015-05-15 19:36:55]

bengr@chromium.org changed reviewers:
+ sclittle@chromium.org

[bengr, 2015-05-15 19:37:35]

bengr@chromium.org changed reviewers:
+ jeremyim@chromium.org
- sclittle@chromium.org

[jeremyim, 2015-05-15 19:39:04]

lgtm

[bengr, 2015-05-15 19:45:43]

The CQ bit was checked by bengr@chromium.org

[commit-bot: I haz the power, 2015-05-15 19:46:50]

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

[commit-bot: I haz the power, 2015-05-15 19:54:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-15 19:54:36]

Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[bengr, 2015-05-19 17:31:25]

The CQ bit was checked by bengr@chromium.org

[bengr, 2015-05-19 17:31:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
jeremyim@chromium.org, mmenke@chromium.org
Link to the patchset: https://codereview.chromium.org/1143503005/#ps40001
(title: "rebase")

[commit-bot: I haz the power, 2015-05-19 17:31:44]

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

[commit-bot: I haz the power, 2015-05-19 19:00:49]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-05-19 19:01:33]

Patchset 3 (id:??) landed as
https://crrev.com/0993cb9f8f775a7c4b40525c55785f389acde1a5
Cr-Commit-Position: refs/heads/master@{#330579}