Mojoify time zone update IPC from browser to renderer

device/time_zone_monitor/public/interfaces/time_zone_monitor.mojom

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 module device.mojom;
 
-interface LightSensor {
-  StartPolling() => (handle<shared_buffer> memory_handle);
-  StopPolling();
+interface TimeZoneMonitor {

[Ken Rockot(use gerrit already), 2016/09/07 14:54:40]

Optional nit: I don't think the concerns which originally motivated this pattern
are valid anymore, so it might be better to use a simple push interface:

  interface TimeZoneMonitor {
    AddClient(TimeZoneMonitorClient);
  };

  interface TimeZoneMonitorClient {
    OnTimeZoneChange(string tz_info);
  };

My rationale:

1. If a specific interface client is misbehaving and not reading messages off
its message pipe, it doesn't matter. The unread messages still are queued on the
receiver's side, not the sender's side, so the worst that can happen is the
client runs itself OOM.

2. If a client is very badly misbehaving and preventing its local EDK from even
reading messages off the underlying system IPC pipe from the browser, then it
CAN cause buffering to build up on the browser side, but that can happen no
matter how we design our mojom interfaces, and we can develop ways to detect
that and kill bad processes in that case.

3. I'm pretty sure everyone I've spoken with about it agrees that the polling
pattern is awkward to build and use, so given #1 and #2 we should just avoid it
moving forward.

WDYT?

+  // Time zone changes are reported along with the new time zone ID.
+  QueryNextTimeZoneChange() => (string tz_info);
 };