[FAB-2027] Proto style fixes

https://jira.hyperledger.org/browse/FAB-2027

Per https://jira.hyperledger.org/browse/FAB-2026 the proto style in
fabric is inconsistent and violates accepted proto style guidelines.

This CR makes the non-golang code invasive proto changes to conform with
the style guide.

In particular, protoc converts lower_underscore_separated to
LowerUnderscoreSeparated which means that most of our existing fields
can be normalized to the official proto style with no code changes.

This does not fix fields which contained upper case abbreviations
particularly fields ending in 'ID' like txID which must become tx_id and
will be translated to TxId.

This does not fix the enum fields which by proto style should be
UPPER_CASE as this will also require code changes.

Change-Id: Id32d6caba43be9e1c6b1f638be284071bf52f0fd
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

protos/common/common.proto

@@ -64,13 +64,13 @@ message Metadata {
 }
 
 message MetadataSignature {
-    bytes signatureHeader = 1; // An encoded SignatureHeader
+    bytes signature_header = 1; // An encoded SignatureHeader
     bytes signature = 2;       // The signature over the concatenation of the Metadata value bytes, signatureHeader, and block header
 }
 
 message Header {
-    ChainHeader chainHeader = 1;
-    SignatureHeader signatureHeader = 2;
+    ChainHeader chain_header = 1;
+    SignatureHeader signature_header = 2;
 }
 
 // Header is a generic replay prevention and identity message to include in a signed payload
@@ -85,15 +85,15 @@ message ChainHeader {
     google.protobuf.Timestamp timestamp = 3;
 
     // Identifier of the chain this message is bound for
-    string chainID = 4;
+    string chainID = 4; // XXX change to channel_id
 
     // An unique identifier that is used end-to-end.
     //  -  set by higher layers such as end user or SDK
     //  -  passed to the endorser (which will check for uniqueness)
     //  -  as the header is passed along unchanged, it will be
     //     be retrieved by the committer (uniqueness check here as well)
     //  -  to be stored in the ledger
-    string txID = 5;
+    string txID = 5; // XXX change to tx_id
 
     // The epoch in which this header was generated, where epoch is defined based on block height
     // Epoch in which the response has been generated. This field identifies a
@@ -140,24 +140,24 @@ message Envelope {
 // in the BlockHeader.  This makes it natural and obvious that the Data is included in the hash, but
 // the Metadata is not.
 message Block {
-    BlockHeader Header = 1;
-    BlockData Data = 2;
-    BlockMetadata Metadata = 3;
+    BlockHeader header = 1;
+    BlockData data = 2;
+    BlockMetadata metadata = 3;
 }
 
 // BlockHeader is the element of the block which forms the block chain
 // The block header is hashed using the configured chain hashing algorithm
 // over the ASN.1 encoding of the BlockHeader
 message BlockHeader {
-    uint64 Number = 1; // The position in the blockchain
-    bytes PreviousHash = 2; // The hash of the previous block header
-    bytes DataHash = 3; // The hash of the BlockData, by MerkleTree
+    uint64 number = 1; // The position in the blockchain
+    bytes previous_hash = 2; // The hash of the previous block header
+    bytes data_hash = 3; // The hash of the BlockData, by MerkleTree
 }
 
 message BlockData {
-    repeated bytes Data = 1;
+    repeated bytes data = 1;
 }
 
 message BlockMetadata {
-    repeated bytes Metadata = 1;
+    repeated bytes metadata = 1;
 }