GitLab

Introduces the SequencedTaskSource interface to //base. This should ultimately
be coalesced with a similar interface used by SequenceManager but this CL was
complex enough in isolation that it was easier to introduce only the basic API
for now.

MessageLoop will as a follow-up expose an API that will allow it to be created
with a custom SequencedTaskSource. This will enable
ScopedTaskEnvironment::MOCK_TIME on custom MessageLoops (i.e. ForUI/ForIO) and
soon after on all threads (not just main thread), since TaskScheduler's delayed
tasks are managed on a MessageLoopForIO. Finally this will allow MOCK_TIME on
TestBrowserThreadBundle (which uses a MessageLoopForUI); nicely rounding out the
MOCK_TIME APIs.

In this CL the following semantics have changed in MessageLoop :
 * MessageLoop::unbound_task_runner_ ->
    - MessageLoop::underlying_task_runner_
    - MessageLoop::task_runner_ still initially set to it
    - but now const to clarify lifetime (and not set to null in
      ~MessageLoop() as this was pointless)
    - Implements SequencedTaskSource
    - Now has a Shutdown() phase so that PostTask() that happen-after
      ~MessageLoop() returns false
      (MessageLoop::Controller::DisconnectFromParent() still required,
      see comment in ~MessageLoop())
 * IncomingTaskQueue (to be renamed to PendingTaskQueue in follow-up) :
    - no longer has a TriageQueue (MessageLoop communicates directly with
      SequencedTaskSource)
    - no longer ref-counted, strictly a member of MessageLoop
    - MessageLoop uses it as storage for tasks it must delay/defer
    - IncomingTaskQueue no longer has a Shutdown() phase, becomes
      dead storage on shutdown and dies with MessageLoop
    - Racy PostTask() on shutdown are now strictly handled between
      MessageLoop and its Controller
 * SequencedTaskSource :
    - the interface MessageLoop feeds from, initially only
      implemented by MessageLoopTaskRunner but will be made customizable
      as a follow-up
 * MessageLoop::SetTaskRunner()
    - still a thing to keep existing use cases alive but will ultimately
      die in favor of providing an external SequencedTaskSource (and
      killing all MessageLoop task_runner dances performed today :))


Note: most new logic in message_loop_task_runner.cc was moved as-is from
incoming_task_queue.cc

Bug: 708584, 860252
Change-Id: I23f40d293d2df6fe41374fad127745f2ff72fbe0
Reviewed-on: https://chromium-review.googlesource.com/1088762
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578809}