cc: Add UMA for tracking decode duration for out of raster decodes.

cc/tiles/checker_image_tracker.cc

Index: cc/tiles/checker_image_tracker.cc
diff --git a/cc/tiles/checker_image_tracker.cc b/cc/tiles/checker_image_tracker.cc
index 022269d87a95fa52d4661581e4c527c4799f32d4..1256bacf8e832b9784dd0864a0d451fdd690a0f7 100644
--- a/cc/tiles/checker_image_tracker.cc
+++ b/cc/tiles/checker_image_tracker.cc
@@ -211,7 +211,8 @@ void CheckerImageTracker::ScheduleNextImageDecode() {
       image_controller_->QueueImageDecode(
           outstanding_image_decode_.value().sk_image(),
           base::Bind(&CheckerImageTracker::DidFinishImageDecode,
-                     weak_factory_.GetWeakPtr(), image_id));
+                     weak_factory_.GetWeakPtr(), image_id),
+          ImageDecodeCache::ImageDecodeType::kCheckerImaging);

[vmpstr, 2017/05/30 20:15:12]

This is a bit awkward. This means that to use this interface, you need to
qualify the caller as one of the available ImageDecodeTypes. 

What's the reason for distinguishing between say checker imaging and js decode?
Can we just say that one source of images comes from the image decode queue, and
the other one comes from raster?

In other words, I'm not sure what you would be able to infer from checker
imaging times vs js decode times (they use the same method of decoding)

[Khushal, 2017/05/30 21:30:32]

Since we use heuristics to decide whether images should be checkered or not, I
wanted to see that we generally checker only on long decodes. And whether that
logic needs more fine-tuning. Do you think that's unnecessary?

 
   image_id_to_decode_.emplace(image_id, base::MakeUnique<ScopedDecodeHolder>(
                                             image_controller_, request_id));