Device Service: Decouple Wake Lock from //content

Wake Lock presents challenges in decoupling from //content:

(1) It is naturally a per-WebContents interface, as it coalesces
requests made from frames within the same WebContents.
(2) On Android, it needs the NativeView of the WebContents in order to
block the screen from going to sleep.

This CL takes the following approach:
(1) Adds the notion of a context ID, which is set on WakeLockServiceContext
and which the Device Service can use to map contexts to NativeViews (via
a callback that is passed in at Device Service construction time by its
embedder).
(2) Adds a WakeLockContext Mojo interface. This interface can be used to
forward requests to bind wake locks from untrusted clients that are made within
the same (trusted-client specific) context.
(3) Adds a WakeLockContextProvider Mojo interface. This interface allows
for getting a WakeLockContext that is associated with a specific context ID.
The WakeLockContext impl uses that context ID on Android to obtain the
NativeView for its context.

Note that the lifetime model of WakeLockContext is somewhat complex: It must
stay alive as long as either
(1) Its Mojo connection is still valid (as the client might make future
    GetWakeLock() calls) OR
(2) There are still live WakeLock instances that it has instantiated (since
    they call into it when they receive Mojo requests from *their* clients).

Consequently, WakeLockContext monitors the state of the connections described
in (1) and (2), dying only when *all* of those connections go away. As a final
subtlety, WakeLockServiceImpl calls back into WakeLockContext from its
destructor, which executes immediately *after* WakeLockContext receives the
callback that that WakeLockServiceImpl instance has experienced a connection
error. WakeLockContext thus posts a task to delete itself rather than deleting
itself synchronously.

BUG=689403
TEST=On Chrome on Android, go to about://flags and turn on "Experimental Web
Platform features." Restart Chrome. Go to
https://colinblundell.github.io/wake_lock.html and verify that the page
says "Wake Lock API found". Verify that if you wait ~40 seconds, the device
goes to sleep. Tap "Block sleep." Verify that if you wait longer than the
above period, the device does not go to sleep. Tap "Unblock sleep" and
verify again that the device goes to sleep after waiting.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2734943003
Cr-Commit-Position: refs/heads/master@{#459719}
31 files changed