This CL may cause a small binary size increase, roughly proportional
to how long it's been since our last AFDO profile roll. For larger
increases (around or exceeding 100KB), please file a bug against
gbiv@chromium.org. Additional context: https://crbug.com/805539

Please note that, despite rolling to chrome/android, this profile is
used for both Linux and Android.

The AutoRoll server is located here: https://autoroll.skia.org/r/afdo-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

As part of the Onion Soup effort to move the PushMessaging feature
into Blink, we need to get rid of this class now that is no longer
used, since the implementation of mojom::PushMessaging inside of
//content/browser (content::PushMessagingManager) communicates now
directly with Blink's blink::PushProvider.

Reason for revert: It broke some builds with:
The file:
//out/Release_x64/win_clang_x86/browser_switcher_bho.dll.pdb
is listed as an input or source for the target:
//chrome/browser/browser_switcher/bho:copy_browser_switcher_binaries
but no targets in the build generate that file.
See for instance https://ci.chromium.org/p/chromium/builders/ci/Jumbo%20Win%20x64/35757

Note: Given that Polymer 3 usage in WebUI is still at an early
exploration phase, its resources are only included in the build for
optimize_webui=false, to not affect release builds for now, while
allowing making progress on other fronts like
- type checking
- bundling
- HTML-to-JS automation
- testing JS module based code wit js2gtest infra

* Switch to using CHROMEG_CALLBACK in GtkUi.
* Remove code that's conditional on GTK version < 3.10. The earlist supported
version is now 3.10.8.
* Ensure correct ordering of NativeThemeGtk::OnThemeChanged and
GtkUi::OnThemeChanged. The ordering was correct before, but was dependent on
glib dispatching events in the right order. Changed GtkUi::OnThemeChanged()
to call NativeThemeGtk::OnThemeChanged().

Implement PushProvider in Blink and update PushManager and PushSubscription

This CL implements a version of content::PushProvider inside Blink itself
that communicates directly via Mojo-based IPC with the implementation of
blink::mojom::PushMessaging in //content/browser (i.e. PushMessagingManager),
and update callers in Blink's PushManager and PushSubscription to use this
new implementation instead of the old one, to be removed in a follow-up CL.

This is less efficient in some cases, but simpler, and a better API map to the
underlying capabilities of TreeNode. It's possible there's a way to make it no
less efficient (by being able to return TreeNode::children() directly), but I
can't figure it out.

Note to sheriffs: This CL imports external tests and adds
expectations for those tests; if this CL is large and causes
a few new failures, please fix the failures by adding new
lines to TestExpectations rather than reverting. See:
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md

This CL creates DirectSharedImageVideoProvider, which does a hop to
the gpu main thread for every SharedImageVideo request. This is
almost identical to what was happening before, just refactored.

GpuVideoFrameFactory is now an implementation detail of the provider
rather than VideoFrameFactoryImpl.

A follow-up CL will provide an implementation of
SharedImageVideoProvider that maintains a pool of SharedImageVideo
objects to provide without hopping to the gpu main thread on the
critical path. It will still post a "MaybeRenderEarly" to the main
thread, but that doesn't need to hold up delivery of the VideoFrame
to the renderer.

Added UI test with same logic of user's journey.
- Added test for rendering a new tab after user inspecting a device.
- Added test for displaying the device descriptors correcty with correct
response and short response. Make sure two views and error can
displayed well, and the mapping effect works.
Also added fake UsbDeviceProxy class to implement the functions that
needed for test.

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}