Adds EngineGeolocationFeature for Blimp Geolocation project.

blimp/common/proto/geolocation.proto

Index: blimp/common/proto/geolocation.proto
diff --git a/blimp/common/proto/geolocation.proto b/blimp/common/proto/geolocation.proto
new file mode 100644
index 0000000000000000000000000000000000000000..a8acd221dac3419bb6725b217c0da391d6f4aa76
--- /dev/null
+++ b/blimp/common/proto/geolocation.proto
@@ -0,0 +1,68 @@
+// 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.
+//
+// Message definitions for geolocation messages.
+
+syntax = "proto2";
+
+option optimize_for = LITE_RUNTIME;
+
+import "common.proto";
+
+package blimp;
+
+message GeolocationErrorMessage {
+  enum ErrorCode {
+    PERMISSION_DENIED = 1;
+    POSITION_UNAVAILABLE = 2;
+    TIMEOUT = 3;
+  }
+
+  optional ErrorCode error_code = 1;
+  optional string error_message = 2;
+}
+
+message GeolocationCoordinates {
+  optional double latitude = 1;
+  optional double longitude = 2;
+  optional double altitude = 3;
+  optional double accuracy = 4;
+  optional double altitude_accuracy = 5;
+  optional double heading = 6;
+  optional double speed = 7;
+}
+
+message GeolocationPositionMessage {
+  optional GeolocationCoordinates coordinates = 1;
+
+  // Client-side time

[Wez, 2016/07/14 01:19:21]

If you check the LocationProvider interface you'll see that there's an
expectation that the timestamp is the browser's notion of time, not the source's
(even in Chrome, the location info might come from a GPS unit with its own clock
:)

I would suggest that we omit this field, for now, and synthesize it when we
receive the location messages at the Engine - it's intended for use by content
in determining the freshness of location information, and so is mainly useful in
getCurrentPosition() results.

When JS receives position change events, by definition those are as fresh as we
can make them, so the timestamp may as well be "now".

[CJ, 2016/07/14 23:55:09]

Ah okay! Did not know that. Updating. 

[Wez, 2016/07/15 01:46:17]

Acknowledged.

+  optional int64 timestamp_millis = 2;
+}
+
+message GeolocationInterestMessage {
+  // These values represent the various listening states the server can have.
+  // A ListenState containing an accuracy level indicates that the server is
+  // waiting for either high or low accuracy position updates from the client.
+  // If a REQUEST_NONE listen state is sent, the server is no longer listening
+  // for updates.

[Wez, 2016/07/14 01:19:21]

My suggestion was to rename ListenState and the enum values to be consistent
with the message terminology.

I'd recommend calling this something like GeolocationSetLevelMessage with enum
called Level and values NO_LOCATION, HIGH_ACCURACY, LOW_ACCURACY. That way there
is a single notion of what "level" of location information the Engine wants,
ranging from none at all to high-accuracy.

[CJ, 2016/07/14 23:55:09]

Done, but slightly different. Thought NO_INTEREST would be better than
NO_LOCATION and keeping Interest in the name to be explicit. 

[Wez, 2016/07/15 01:46:17]

Acknowledged.

+  enum ListenState {
+    REQUEST_NONE = 0;
+    ACCURACY_HIGH = 1;
+    ACCURACY_LOW = 2;
+  }
+
+  optional ListenState listen_state = 1;
+}
+
+message GeolocationMessage {
+  oneof type {
+    // Server => Client types.
+    GeolocationInterestMessage update_listen_state = 1;
+    EmptyMessage request_refresh = 2;
+
+    // Client => Server types.
+    GeolocationPositionMessage location = 3;
+    GeolocationErrorMessage error = 4;
+  }
+}