Ensure we compute the proper scroll duration and don't over estimate.

Currently some events will extend beyond and because of our conditional
selecting the Scroll end they'll have different values, but since we're
grouping by scrollBeginId we will sum it multiple times when we should only sum
it once.

Bug: internal bug: b/150867143
Change-Id: I58c4c163e1ce8dc8760973f10e8532bcce2e8bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2100750
Auto-Submit: Stephen Nusko <nuskos@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/master@{#749782}

tools/perf/core/tbmv3/metrics/janky_time_per_scroll_processing_time.sql

@@ -243,6 +243,10 @@ CREATE TABLE ScrollJanks AS
 -- ensure our devision results in a percentage and not just integer division
 -- equal to 0.
 --
+-- We need to select MAX(currScrollDur) because the last few
+-- GestureScrollUpdates might extend past the GestureScrollEnd event so we
+-- select the number which is the last part of the scroll.
+--
 -- TODO(nuskos): We should support more types (floats and strings) in our
 --               metrics as well as support for specifying units (nanoseconds).
 
@@ -256,14 +260,13 @@ CREATE TABLE JankyNanosPerScrollNanosMaybeNull AS
       0 END) as jankyNanos,
     SUM(currUpdateDur) AS totalProcessingNanos,
     (
-      SELECT sum(currScrollDur)
+      SELECT sum(scrollDur)
       FROM (
         SELECT
-          currScrollDur
+          MAX(currScrollDur) AS scrollDur
         FROM ScrollJanks
         GROUP BY currBeginId
       )
-      LIMIT 1
     ) AS scrollNanos
   FROM ScrollJanks;