Rework UMAHistogramHelper and StatisticsDeltaReader into [Chrome]HistogramTester.

content/public/test/browser_test_utils.cc

Index: content/public/test/browser_test_utils.cc
diff --git a/content/public/test/browser_test_utils.cc b/content/public/test/browser_test_utils.cc
index 0af7c636bc733af8f87b95e5a560e1bba92b43a1..9a3879f9364206a2e043123a74c780adf0480c31 100644
--- a/content/public/test/browser_test_utils.cc
+++ b/content/public/test/browser_test_utils.cc
@@ -4,6 +4,7 @@
 
 #include "content/public/test/browser_test_utils.h"
 
+#include "base/bind.h"
 #include "base/command_line.h"
 #include "base/json/json_reader.h"
 #include "base/path_service.h"
@@ -19,6 +20,7 @@
 #include "content/common/input/synthetic_web_input_event_builders.h"
 #include "content/public/browser/browser_context.h"
 #include "content/public/browser/dom_operation_notification_details.h"
+#include "content/public/browser/histogram_fetcher.h"
 #include "content/public/browser/notification_service.h"
 #include "content/public/browser/notification_types.h"
 #include "content/public/browser/render_frame_host.h"
@@ -594,6 +596,20 @@ bool SetCookie(BrowserContext* browser_context,
   return result;
 }
 
+void FetchHistogramsFromChildProcesses() {
+  scoped_refptr<content::MessageLoopRunner> runner = new MessageLoopRunner;
+
+  FetchHistogramsAsynchronously(
+      base::MessageLoop::current(),
+      runner->QuitClosure(),
+      // If this call times out, it means that a child process is not
+      // responding, which is something we should not ignore.  The timeout is
+      // set to be longer than the normal browser test timeout so that it will
+      // be prempted by the normal timeout.
+      TestTimeouts::action_max_timeout() * 2);

[Paweł Hajdan Jr., 2014/07/23 10:50:58]

The timeouts returned by TestTimeout should not be multiplied.

There must be some better solution than this.

[Ilya Sherman, 2014/07/23 17:25:11]

What is your objection to multiplying the timeout?  The goal is to have the test
time out if the FetchHistogramsAsynchronously call fails (also with a timeout). 
The multiplication isn't strictly necessary, I suppose; using
action_max_timeout() directly should, in theory, given the same result.

[brettw, 2014/08/04 05:45:49]

I agree with Pawel. We shouldn't have arbitrary timeouts unless there is some
specific justification. Using action_max_timeout directly should be sufficient.
If this isn't long enough, we have a different problem.

+  runner->Run();
+}
+
 TitleWatcher::TitleWatcher(WebContents* web_contents,
                            const base::string16& expected_title)
     : WebContentsObserver(web_contents),