Add compiled protobuf files

[RyanLassigBanks]

Adding compiled protobuf files to make it easier to use the Go SDK with Go modules

Signed-off-by: Ryan Banks rbanks@bitwise.io

[dplumb94]

@vaporos

First, absolutely we can not trust this to be a stable API as the generation procedure may change the API in the future, so we need a code refactor to hide these generated files from SDK users.

Agreed, but including the generated protos doesn't change this situation. In order to use the Go SDK currently, a user has to vendor the Go SDK and then manually run the go generate script to generate the protos inside the vendored directory. After that, the API of the generated files is still exposed to the user. For example, here is how it is imported in Seth: https://github.com/hyperledger/sawtooth-seth/blob/master/processor/src/seth_tp/handler/handler.go#L32

It seems to me that requiring an SDK consumer to take these steps is worse than including the generated files in the repo. I also haven't found a way to use the SDK with Go's new module system. Further, including generated files in the package is the recommended approach in the Go documentation, due to the limitations of go: https://golang.org/doc/articles/go_command.html#tmp_4

I agree that we need to update the usage instructions before merging if we do switch to this method. We could also regenerate them in CI and test that there is no diff between the generated files and what is checked in.

I'm definitely open to other solutions, but so far I haven't seen one that is less painful than checking in the generated files for Go.

[arsulegai]

I do not see go generate a concern. But if running go generate after getting the SDK in the vendor directory is a problem then the other approach could be to write a download + install script. User has to download the new script and execute it! rest of the things for setting up the SDK on the dev machine will be taken care. The script could alternatively read and make use of the Go env variables.