Set up the infrastructure for Extension event metrics.

extensions/browser/event_router.h

Index: extensions/browser/event_router.h
diff --git a/extensions/browser/event_router.h b/extensions/browser/event_router.h
index b9af93aef3e402644505b597e888e5a1ff602198..8164d91523b901d56624a39e679a2ee8908e17dc 100644
--- a/extensions/browser/event_router.h
+++ b/extensions/browser/event_router.h
@@ -22,6 +22,7 @@
 #include "content/public/browser/notification_registrar.h"
 #include "content/public/browser/render_process_host_observer.h"
 #include "extensions/browser/event_listener_map.h"
+#include "extensions/browser/extension_event_histogram_value.h"
 #include "extensions/browser/extension_registry_observer.h"
 #include "extensions/common/event_filtering_info.h"
 #include "ipc/ipc_sender.h"
@@ -335,6 +336,11 @@ struct Event {
                               const Extension*,
                               base::ListValue*)> WillDispatchCallback;
 
+  // The identifier for the event, for histograms. In most cases this

[not at google - send to devlin, 2015/06/22 23:42:11]

Look here.

[Devlin, 2015/06/23 17:20:43]

When will an event generate its own name?  If it weren't for that, this would be
a lot cleaner and more stable by passing in only one of these.

[not at google - send to devlin, 2015/06/23 17:49:09]

What do you mean "generate its own name"? I agree it would be more stable to
only pass in one of these, and I looked into that initially (I liked the idea of
enumerating the possible events then mapping that onto strings) but there are
some problems with this.

Mainly, dependency management. Idiomatically, even this histogram thing is
borderline breaking the extensions-module-is-separate thing, and pulling all
event *names* into the extension module is further down that path. Histogram
names are a weak dependency. Event names are not.

There are a couple of other problems that aren't worth going into so much -
they're solvable, but do increase the yak size. Generally I think this would be
a pretty dangerous path to take. I can predict exactly how complex this is going
to be: this patch, and subsequent patches to use the right event histogram
enums. More fundamentally changing how we dispatch events... I can't so well
predict what might happen there, but much more could go wrong.

[Devlin, 2015/06/23 17:55:56]

By "generate its own name", I mean whatever you meant on line 340-341 with "in
some cases events will generate their own names". ;)  And yeah, it would be kind
of a pain, but relatively solvable - I could see something like having a mapping
on the extensions/ side and the chrome/ side, and we check in the former first,
followed by the latter if it's not present.  But I do see what you mean about it
increasing size.

All that said, original question stands - when will events generate their own
names?

[not at google - send to devlin, 2015/06/23 17:59:01]

APIs which have their schemas compiled will get event names generated, that is
what the comment is referred to. Not all schemas are compiled though.

OTOH there is no way for the schema to generate a histogram identifier because
the order is not predictable and would mess up the histogram.

[Devlin, 2015/06/23 18:07:38]

Ah, gotcha.  So in that case, it would be fairly easy to have a chrome/ and
extensions/ mapping of histogram values to event names, and it would also ensure
that we never create an event with the wrong name/value (and prevent callers
from needing to pass in duplicate values).  Apart from the obvious overhead of
creating the maps, is there a big downside?  (I'm not sure I follow how this
would be "fundamentally changing how we dispatch events...)

+  // correlates 1:1 with |event_name|, in some cases events will generate
+  // their own names, but they cannot generate their own identifier.
+  events::HistogramValue histogram_value;
+
   // The event to dispatch.
   std::string event_name;
 
@@ -366,14 +372,17 @@ struct Event {
   // this event to be dispatched to non-extension processes, like WebUI.
   WillDispatchCallback will_dispatch_callback;
 
-  Event(const std::string& event_name,
+  Event(events::HistogramValue histogram_value,
+        const std::string& event_name,
         scoped_ptr<base::ListValue> event_args);
 
-  Event(const std::string& event_name,
+  Event(events::HistogramValue histogram_value,
+        const std::string& event_name,
         scoped_ptr<base::ListValue> event_args,
         content::BrowserContext* restrict_to_browser_context);
 
-  Event(const std::string& event_name,
+  Event(events::HistogramValue histogram_value,
+        const std::string& event_name,
         scoped_ptr<base::ListValue> event_args,
         content::BrowserContext* restrict_to_browser_context,
         const GURL& event_url,