Use lower_camel_case consistently for fields in protobuf definitions

[joshuagl]

We claim to adhere to the protobuf programming practices, and thus should also follow the style guide there.

The style guide states that message field names should be lower_snake_case, not lowerCamelCase. Our protobuf definitions are somewhat inconsistent, this PR normalises to lower_snake_case for field names in protobuf definitions.

Fixes: #250

[marcelamelara]

Thanks @joshuagl ! These changes shouldn't break the tests, right?

[joshuagl]

Thanks @joshuagl ! These changes shouldn't break the tests, right?

This PR does not appear to break the tests.
Alas, the tests are already broken. I've proposed a fix in #259. With that fix and this branch combined, the tests pass.

[TomHennen]

So the generated API stays the same? Seems like a win.

[joshuagl]

Alas, no. The generated API does change. Presumably the changed API is not covered by current tests, though? make go_test succeeds after my change is merged (it even uses cached results, further indicating the changed API is not covered by the tests).

[marcelamelara]

Hmm, the changed APIs should be covered in the tests AFAIK (I wrote them), in that the tests do some (un)marshalling of RD and Statement protos. I wonder now if the JSON protobuf API used in the tests treats the updated API as equivalent? I can look into this, but since the tests are working fine, we can probably leave this for another PR.

[joshuagl]

Apologies, it turns out I was wrong. I just did a manual review of the proto changes with this series applied, you can see the diff I've reviewed in a gist https://gist.github.com/joshuagl/ae743664f4422391d6e88010b1d167c0

The Go API is unchanged: struct names remain the same

[adityasaky]

This is interesting:

-	DownloadLocation string                     `protobuf:"bytes,5,opt,name=downloadLocation,proto3" json:"downloadLocation,omitempty"`
-	MediaType        string                     `protobuf:"bytes,6,opt,name=mediaType,proto3" json:"mediaType,omitempty"`
+	DownloadLocation string                     `protobuf:"bytes,5,opt,name=download_location,json=downloadLocation,proto3" json:"download_location,omitempty"`
+	MediaType        string                     `protobuf:"bytes,6,opt,name=media_type,json=mediaType,proto3" json:"media_type,omitempty"`

If I'm parsing this right, when the proto is snake cased, the json tag supports JSON docs with snake cased keys but also the camelcased ones (I know there's default conversion somewhere in there).

Thinking about it more, I guess we knew this because in-toto v1 links are snake cased but there are proto definitions that support them...