Add histograms for ExternalDataUseObserver

chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java

Index: chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java b/chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java
index 44b0ab5f2c2f16829cbdbcd81db8831b0928e6ee..e298d986f687d11f0142be661481e981e8db4f39 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/datausage/ExternalDataUseObserver.java
@@ -88,7 +88,8 @@ public class ExternalDataUseObserver {
      * @param bytesUploaded number of bytes uploaded by Chromium.
      * The result of this request is returned asynchronously via
      * {@link #nativeOnReportDataUseDone}. A new report should be submitted only after the
-     * result has been returned via {@link #nativeOnReportDataUseDone}.
+     * result has been returned via {@link #nativeOnReportDataUseDone}. Submitting another data
+     * use report while the previous is pending may cause the previous report to be lost.

[sclittle, 2015/12/08 02:25:41]

This new sentence contradicts the previous sentence. You should be specific
here, e.g. that the previous report should be cancelled and that
nativeOnReportDataUseDone will not be called for that cancelled report.

[tbansal1, 2015/12/08 04:04:32]

There is no concept of canceling a report. Actually, there is no way o cancel it
because of there is a timeout, it is impossible to know where the execution got
stuck. May be the external observer (e.g., Google Play Service received it,
accepted it but the confirmation back got lost somewhere).

Again, it is not guaranteed that nativeOnReportDataUseDone will not be called.
It may still get called depending on where the timeout happened. Also, e.g.,
nativeOnReportDataUseDone may be called on a different thread. So, it may get
called at 5 minute 0.01 second.

Only guarantee is that if two reports are submitted at the same time, then the
first one *may* be lost.

This is not the best solution but right now the goal is to (i) know how
frequently reports are lost in the wild; (ii) Not block forever in case the
callback never comes. Hopefully, the number is low enough.

[sclittle, 2015/12/09 19:42:59]

OK, could you reword/remove the previous sentence, about how new reports
shouldn't be submitted while another is in progress, since that's not true -
e.g., timeouts are a case where the new report *should* be submitted.

You can just keep the new sentence you've added here.

[tbansal1, 2015/12/10 00:41:39]

Done.

      */
     @CalledByNative
     protected void reportDataUse(String label, int networkType, String mccMnc,