Reland "Reland "Scroll scrollbar presses with gestures""

This is a reland of 77a8bf44f6130d08857f2715efdf8e4f31e8eb3e

Original change's description:
> Reland "Scroll scrollbar presses with gestures"
>
> This is a reland of 5fcb73a6bd727b53e9e5d5c0b6b203a17362b600, but now
> behind a feature flag, along with fixes for regressions caused by the
> original change - crrev.com/c/1600444, crrev.com/c/1614283
>
> Bug: 954007,960747,963249,963825
>
> Original change's description:
> > Scroll scrollbar presses with gestures
> >
> > We don't currently track scrollbar scrolling latency - scrollbar
> > scrolling is currently performed on the main thread in response to
> > mouse events, so commits caused by this are categorized as LatencyInfo
> > with MOUSE type.
> >
> > With the work being done to move scrollbar scrolling to the compositor
> > thread (feature CompositorThreadedScrollbarScrolling), we want to be
> > able to track how latency changes (presumably improves) when we roll
> > out the feature in experiments. In order to do so we need to classify
> > scrolls that originate from scrollbars separately - this change adds
> > the foundation of how to accomplish this on the main thread.
> >
> > Instead of blink::Scrollbar directly scrolling its ScrollableArea in
> > response to a mouse input event, it will instead queue up a series of
> > scroll gestures, targetted at the ScrollableArea. A new method on
> > WebWidgetClient is exposed which adds the ability to inject these
> > synthesized gesture events. This is implemented in content in one of
> > two fashions:
> > - If the injection request happens during the handling of an input
> > event, the gesture(s) will be dispatched directly once the current
> > dispatch of the input event is complete.
> > - Otherwise, it gets queued up on the main thread event queue.
> > The latter condition comes into play when the autoscroll timer fires
> > due to holding down the mouse on the button or track.
> >
> > The reason for this distinction is due to the way the main thread event
> > queue dispatches events - it only dispatches the events that were
> > queued prior to running. If we always queued events, for rAF aligned
> > input (i.e. mouse-move) we'd be introducing a frame of latency as
> > the scroll would not be executed before the commit that occurs after
> > dispatching the rAF aligned input.
> >
> > This also has the nice side effect creating a mechanism to further
> > unify main thread scrolling (i.e. keyboard scrolling can be converted
> > to this code path as well).
> >
> > Once this mechanism is in place, we will dispatch the injected events
> > with a LatencyInfo with a modified type. This will be done in a follow
> > up change, as well as another one to convert the remaining scrolls
> > from blink::Scrollbar to use this gesture-based system.
> >
> > Bug: 954007
> > Change-Id: I5da338103e833f2e909bc3163b618f57bd7142c4
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1580588
> > Commit-Queue: Daniel Libby <dlibby@microsoft.com>
> > Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> > Reviewed-by: David Bokan <bokan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#657031}
>
> Change-Id: I2adab7c04ac8b36ceb9cda16e5a775fd2b1edb49
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1619331
> Commit-Queue: Daniel Libby <dlibby@microsoft.com>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: David Bokan <bokan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#663201}

TBR=bokan@chromium.org, dcheng@chromium.org

Bug: 954007, 960747, 963249, 963825
Change-Id: I2ccb588cd97e51db13f75c50b6335accf7079d83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1629054
Reviewed-by: Daniel Libby <dlibby@microsoft.com>
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#663359}
33 files changed