Add support for (de)serializing cc::Layer hierarchy.

cc/proto/layer.proto

Index: cc/proto/layer.proto
diff --git a/cc/proto/layer.proto b/cc/proto/layer.proto
new file mode 100644
index 0000000000000000000000000000000000000000..44ee229f92bae02989b52c7d54446a1013cdb144
--- /dev/null
+++ b/cc/proto/layer.proto
@@ -0,0 +1,30 @@
+// 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.
+
+syntax = "proto2";
+
+package cc.proto;
+
+option optimize_for = LITE_RUNTIME;
+
+// Identifies the type of cc:Layer a LayerNode represents. It is used to
+// facilitate reconstruction of a Layer of the correct type on the client.
+enum LayerType {
+  Base = 1;
+
+  // TODO(nyquist): Add the rest of the necessary LayerTypes.
+};
+
+// Hierarchical structure for serializing the Layer tree.
+message LayerNode {
+  // required

[vmpstr, 2015/10/21 22:34:14]

I made a few comments throughout the code, but I think you should just DCHECK
fields that are required by the protocol

[nyquist, 2015/10/23 00:12:31]

I've implemented this.

To explain my reasoning: We are receiving this over a network channel, where
things can go bad over the wire, or a server that is misbehaving, etc. I figured
I'd code defensively and ensure we don't use bad data. However, I realize that
we should instead do some kind of validation of the data at a higher level
possibly instead, and have a way of recovering from it (asking server to re-send
or re-initialize, etc.) instead of littering the code with if-statements and
ending up with badly constructed objects.

[vmpstr, 2015/10/23 21:26:10]

Ya that's totally understandable. However, at this point, I'd prefer to dcheck
everything instead of handle error cases. The reason for that is that bugs that
we introduce now could cause these error condition and go unnoticed for a long
time, because we handled them. If we DCHECK, we can catch the bugs now. In the
future, when DCHECKs fail incorrectly or if the protocol changes, then maybe we
can add error handling.

This is partly the reason why I asked (here or in some other patch) on what the
story is for server evolving separately from the client. That's an important
thing to get right.

+  optional uint32 id = 1;
+  // required
+  optional LayerType type = 2;
+  optional uint32 parent_id = 3;
+  // A List of all the children of the current LayerNode.
+  repeated LayerNode children = 4;
+  optional LayerNode mask_layer = 5;
+  optional LayerNode replica_layer = 6;
+}