Add metrics for calculating precision/recall of link navigation pre-connect triggers.

chrome/browser/net/predictor.cc

Index: chrome/browser/net/predictor.cc
diff --git a/chrome/browser/net/predictor.cc b/chrome/browser/net/predictor.cc
index 9afc3742742c77de58222676959671eced95d6ec..03347f449a0220206bc5f4f5b37284ad96aedbb7 100644
--- a/chrome/browser/net/predictor.cc
+++ b/chrome/browser/net/predictor.cc
@@ -847,6 +847,10 @@ void Predictor::PreconnectUrlOnIOThread(
     const GURL& url, const GURL& first_party_for_cookies,

[jar (doing other things), 2013/06/10 03:17:16]

nit: one arg per line for definitions and declarations.

If you clean up this line, you might want to do the same to other instances in
this file.

I think the coding style evolved (in a positive direction), and at a minimum you
should clean up any method/function that you piddle with.

[kouhei (in TOK), 2013/06/10 23:24:05]

Ack.

[kouhei (in TOK), 2013/06/14 16:49:42]

I would like to address this in other CL.

     UrlInfo::ResolutionMotivation motivation, int count) {
   GURL canonical_url(CanonicalizeUrl(url));
+
+  UMA_HISTOGRAM_BOOLEAN(
+      "Net.PreconnectsUnique",
+      recent_preconnects_.WasRecentlySeen(canonical_url));

[jar (doing other things), 2013/06/10 03:17:16]

Why is this an interesting stat?

I expect that connection pooling will disregard any extraneous or repeated
preconnect requests, so why do we care if we request preconnects more than once
(in a short(?) period of time?

   recent_preconnects_.SetRecentlySeen(canonical_url);
 
   PreconnectOnIOThread(url,