Add UNKNOWN values to blimp proto enums

blimp/common/proto/blimp_message.proto

 // Copyright 2015 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.
 //
 // Contains the BlimpMessage proto which frames all messages sent over Blimp
 // subchannels. BlimpMessage protos are serialized and transmitted over the
 // wire to the Blimplet server.
 //
 // Each BlimpMessage has a few identifying fields which provide the browser
 // session and tab ID as context. The message details are stored in a
@@ skipping 15 matching lines @@
 
 import "control.proto";
 import "compositor.proto";
 import "input.proto";
 import "navigation.proto";
 
 package blimp;
 
 message BlimpMessage {
   enum Type {
-    COMPOSITOR = 0;
-    INPUT = 1;
-    CONTROL = 2;
-    NAVIGATION = 3;
+    UNKNOWN = 0;

[maniscalco, 2015/11/20 22:33:48]

Breaking the cardinal rule here, but I believe it's OK because there is nothing
"in the wild" for us to break.  Of course if we have serialized protos stashed
away somewhere (files for replay, databases, etc.).  We'd need to update those
as well.

[Wez, 2015/11/20 23:33:39]

Agreed; we are OK w/ breaking changes to the protocol at least until we reach
the v0.5 milestone, FWIW.

nit: Is UNKNOWN the convention, or INVALID?  Fundamentally, via versioning, a
peer sending out-of-range values is misbehaving, so I'd treat that as invalid
input.

[maniscalco, 2015/11/20 23:42:21]

The convention I'm familiar with is to use UNKNOWN or FOO_UNKNOWN where FOO is
the name of the enum.

I understand what you mean about it being invalid in our use.  My instinct is to
stick with UNKNOWN since it's more common, but I'm happy to change it if you
feel strongly.

+    COMPOSITOR = 1;
+    INPUT = 2;
+    CONTROL = 3;
+    NAVIGATION = 4;
   }
   // Identifies the feature type of this message.
   // The feature-specific contents are contained in optional fields of the same
   // name (example: use |compositor| field for type=COMPOSITOR.)
   optional Type type = 1;
 
   // Uniquely identifies the Blimp session that originated this message.
   // Session IDs are invalidated whenever new sessions are created.
   // If a message's |session_id| does not match the client's session ID,
   // then the message may have originated from a discarded session and can be
   // safely ignored.
   optional int32 session_id = 2;
 
   // ID of the tab that is referenced by this message.
   // Messages that are tab-agnostic may leave this field unset.
   optional int32 target_tab_id = 3;
 
   // Feature-specific messages follow.
   // Only one of these fields may be set per BlimpMessage.
   // TODO(kmarshall): use a 'oneof' union when it's supported in Chromium.
   optional CompositorMessage compositor = 1000;
   optional InputMessage input = 1001;
   optional ControlMessage control = 1002;
   optional NavigationMessage navigation = 1003;
 }