proto: re-export prost_types as well_known_types

[tarcieri]

My main interest is being able to get to prost_types::Timestamp without having to include prost_types in addition to
tendermint-proto, however I think there might be more cases where it's helpful to have access to the well-known proto types in the future.

[codecov-io]

Codecov Report

Merging #658 into master will increase coverage by 0.3%.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           master    #658     +/-   ##
========================================
+ Coverage    43.4%   43.7%   +0.3%     
========================================
  Files         169     175      +6     
  Lines       11828   11898     +70     
  Branches     2721    2720      -1     
========================================
+ Hits         5141    5208     +67     
- Misses       6410    6411      +1     
- Partials      277     279      +2     

Impacted Files	Coverage Δ
proto/src/lib.rs	100.0% <ø> (ø)
rpc/src/query.rs	72.6% <0.0%> (-2.1%)	⬇️
tendermint/src/proposal.rs	73.5% <0.0%> (-0.6%)	⬇️
tendermint/src/vote.rs	66.3% <0.0%> (-0.4%)	⬇️
tendermint/src/vote/sign_vote.rs	85.3% <0.0%> (-0.3%)	⬇️
testgen/src/vote.rs	79.4% <0.0%> (-0.2%)	⬇️
light-client/src/operations/voting_power.rs	86.4% <0.0%> (-0.2%)	⬇️
light-client/src/macros.rs	15.4% <0.0%> (-0.1%)	⬇️
tendermint/tests/config.rs	100.0% <0.0%> (ø)
light-client/src/evidence.rs	0.0% <0.0%> (ø)
... and 29 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 34a2386...c1cc891. Read the comment docs.

[liamsi]

I think that makes sense! LGTM 👍 I'll let Greg have the final say on this PR as I'm bit out of loop on everything proto-related currently.

[thanethomson]

If it helps you @tony-iqlusion, it makes sense to me 😁

@greg-szabo, any objections from your side?

[tarcieri]

Looks like this is also addressed in #653? (at least according to @greg-szabo although I'm not quite sure where/how)

[greg-szabo]

Apologies, I gave Tony the wrong PR number. In #639 we dissected prost_types and added our own implementation so they can be serialized as JSON objects. So, there is a tendermint_proto::google::protobuf::Timestamp and similar on master right now.

But we are trying to separate protobuf and JSON serialization in an upcoming RC and it's possible that we won't need to dissect prost_types (because it's cumbersome and hacky). In that case, this idea is nice.

To keep things manageable (although not the simplest), I suggest that you use the tendermint_proto::google::protobuf types instead of the prost_types in RC2 (soon to be released). IF we make the decision to not build our own prost_types, then the tendermint_proto::well_known_types is a good solution to keep life simple. (A possibility in RC3.)

But I would rather not add both to RC2 to avoid confusion.

If anyone has strong opinions in adding it to RC2, please raise it here. Maybe I'm the only one who would get confused. :)

[tarcieri]

tendermint_proto::google::protobuf works for me!