This could make it easier to implement nested workers ( issue 31666 )

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf

commit 5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Wed Jul 05 07:30:51 2017

Worker: Always return default task runners of the main thread when a frame is not given

Before this CL, ParentFrameTaskRunners::Create() with null-LocalFrame returns
default task runners of the current thread. Service workers call it in such a
manner because they don't have an associated frame. That creation function is
supposed to be called on the main thread, so the returned task runners should
always be default task runners of the main thread.

After this CL, the creation function is separated into two functions:
Create(LocalFrame&) and Create(). The former is equivalent to the previous
Create() with non-null-LocalFrame and always returns task runners associated
with the given frame. The latter is equivalent to the previous Create() with
null-LocalFrame and always returns default task runners of the main thread
regardless of the calling thread.

This enables service workers to create ParentFrameTaskRunners on
non-main-threads, and is useful for supporting off-main-thread service worker
start because it bypasses the main thread on startup and doesn't give a chance
to create the task runners on the main thread.

Bug: 692909
Change-Id: I1d5ac4e4515c5abddacb0b156957e04ca74a5f2e
Reviewed-on: https://chromium-review.googlesource.com/558761
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484208}
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/exported/WebSharedWorkerImpl.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/html/canvas/CanvasAsyncBlobCreator.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/loader/ThreadableLoaderTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/workers/ParentFrameTaskRunners.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/workers/ParentFrameTaskRunners.h
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/workers/ThreadedMessagingProxyBase.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/core/workers/WorkerThreadTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/compositorworker/AnimationWorkletGlobalScopeTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/compositorworker/AnimationWorkletThreadTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThreadTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/exported/WebEmbeddedWorkerImpl.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerGlobalScopeProxy.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/webaudio/AudioWorkletGlobalScopeTest.cpp
[modify] https://crrev.com/5f35c48e0f78a626c1ae7c5a7c21bd87329bfedf/third_party/WebKit/Source/modules/webaudio/AudioWorkletThreadTest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c80ba27ce0942996dbed1e4f57129475492f37a

commit 0c80ba27ce0942996dbed1e4f57129475492f37a
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Thu Aug 10 07:07:49 2017

ServiceWorker: Clarify thread affinity of methods on ServiceWorkerGlobalScopeProxy

Future optimization like off-main-thread service worker start could unexpectedly
churn thread affinity. This CL is a guard againt such the mistake.

Bug: 692909
Change-Id: Iffc401cfe707c8406353411d6eb6499114fb4c81
Reviewed-on: https://chromium-review.googlesource.com/602100
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493314}
[modify] https://crrev.com/0c80ba27ce0942996dbed1e4f57129475492f37a/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerGlobalScopeProxy.cpp
[modify] https://crrev.com/0c80ba27ce0942996dbed1e4f57129475492f37a/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerGlobalScopeProxy.h