Move data use measurement to DataUseNetworkDelegate

components/data_use_measurement/core/DEPS

Index: components/data_use_measurement/core/DEPS
diff --git a/components/data_use_measurement/core/DEPS b/components/data_use_measurement/core/DEPS
index 8fa9d48d882c65ff66720258905d4ce9964b0928..4fd71deafc110a1b552f408baebafa239d212f99 100644
--- a/components/data_use_measurement/core/DEPS
+++ b/components/data_use_measurement/core/DEPS
@@ -1,3 +1,6 @@
 include_rules = [
   "+net",
+  "+components/metrics",
+  "+content/public/common",

[Not at Google. Contact bengr, 2016/11/01 21:32:04]

data_use_measurement/core/ should not depend on content/.

I agree with the general direction of this cl that DataUseMeasurement could use
data_use_measurement/ rather than being hardcoded in ChromeNetworkDelegate.

You have a number of options:
1) Allow observers on DataUseAscriber. Then DataUseMeasurement could just be an
obsever of DataUseAscriber. This functionality will be required for other
purposes such as Page Size Pingback. You could postpone this cl until the
observer functionality is in, or add it yourself.

2) It seems the only reason DataUseMeasurement class is in content is because of
dependency on ResourceRequestInfo for IsUserInitiatedRequest().
DataUseMeasurement could be given a callback that given a URLRequest can tell
whether it is user initiated. The callback interface would be defined in core/
and the implementation under /content.

[Raj, 2016/11/08 22:39:31]

I am following option#2.

option#1 will not be enough for my usecase to get datause of various
combinations such as chrome app in background/foreground, chrome tab in
background/foreground, screen on/off, etc. Part of this info is obtained from
web content observers and remaining from other places. So DataUseMeasurement
needs to fuse all these info together. Observers on DataUseAscriber would be as
simple as returning datause for a tab/webcontent, and do not consider these
various combinations.

+  "+content/public/browser",
 ]