compositor worker: Use a WebThread for the compositor thread.

components/scheduler/child/webthread_impl_for_worker_scheduler.h

Index: components/scheduler/child/webthread_impl_for_worker_scheduler.h
diff --git a/components/scheduler/child/webthread_impl_for_worker_scheduler.h b/components/scheduler/child/webthread_impl_for_worker_scheduler.h
index a1982379898df9c82ec4b66141dfc8dbab74db7c..37bdff6b870251f529578edd592a81c8b44332d4 100644
--- a/components/scheduler/child/webthread_impl_for_worker_scheduler.h
+++ b/components/scheduler/child/webthread_impl_for_worker_scheduler.h
@@ -33,6 +33,8 @@ class SCHEDULER_EXPORT WebThreadImplForWorkerScheduler
                                   base::Thread::Options options);
   ~WebThreadImplForWorkerScheduler() override;
 
+  void Init();
+
   // blink::WebThread implementation.
   blink::WebScheduler* scheduler() const override;
   blink::PlatformThreadId threadId() const override;
@@ -46,6 +48,12 @@ class SCHEDULER_EXPORT WebThreadImplForWorkerScheduler
   void WillDestroyCurrentMessageLoop() override;
 
  private:
+  // Returns whether the base::Thread's task-runner should be used as the
+  // default task runner (returns true), or the default task runner from the
+  // scheduler should be used instead (returns false). The default behaviour is
+  // to use the scheduler's default task runner.
+  virtual bool UseThreadTaskRunnerAsDefault() const;

[Sami, 2016/01/13 17:17:05]

This is a dangerous API because tasks will run in a different order depending on
which task queue they end up using, which can cause hard-to-diagnose breakage.
Could we instead try to find out what part of the scheduler code was responsible
for the regression and optimize that? I wouldn't expect the worker scheduler to
have that much overhead compared to a plain message loop -- but I might be wrong
since it's been a while since we last measured this.

[sadrul, 2016/01/13 18:29:32]

Indeed, that's what I was worried about. A different implementation of
WorkerScheduler should avoid that from happening, right? I have implemented that
in the latest patchset (it now depends on
https://codereview.chromium.org/1585723002/).
It's actually not clear exactly what is causing the regression. As you say,
WorkerSchedulerImpl doesn't do a whole lot. It does install its own task runner
on the thread, and that seems sufficient to trigger the regression. I am not
familiar with this enough to understand how to go about finding the code
responsible for the regression. Any advice? And in the meantime, would it be
acceptable to have a CompositorWorkerScheduler implementation for
WorkerScheduler (see latest patchset)?

+
   void AddTaskObserverInternal(
       base::MessageLoop::TaskObserver* observer) override;
   void RemoveTaskObserverInternal(