Add file_descriptor option to prost-build

[jen20]

This pull request adds support for including an encoded version of the appropriate FileDescriptorProto in each generated Rust module in the form of a &'static [u8] named FILE_DESCRIPTOR. This is disabled by default, and is enabled by setting file_descriptor(true) in a Config builder.

The rationale for this pull request is to support the gRPC Server Reflection Protocol, which operates in terms of FileDescriptorProto, in Tonic.

[danburkert]

A few thoughts in no particular order:

The correspondence between .proto files and generated Rust modules is n:1, not 1:1. As such, I think if you were to test this with two .proto files in the same package, it would fail to compile due to duplicate FILE_DESCRIPTOR symbols.

I think this would be more elegantly expressed with include_bytes!() as opposed to inlining the descriptor proto into the generated rust source.

Looking at the provided link on gRPC server reflection, the corresponding C++ code uses DescriptorDatabase. If you look at how the Descriptor machinery works for e.g. C++ generated code, it involves a lot of static init ctor magic. I'm not too keen on adding that kind of thing to prost, but it's probably an inevitability if prost is going to get good generic/reflective capabilities. I'd strongly strongly prefer to use something not homebrew for this, such as https://github.com/dtolnay/inventory.

[danburkert]

Perhaps a better approach would be to include the FileDescriptorSet instead of the FileDescriptor. I'm not sure if there's an obvious place to 'mount' that, though. Perhaps prost could just serialize it to a file in a well-known-location, and tonic could include_bytes! it?

[jen20]

Ah, I didn't quite appreciate that there was not a 1-1 correspondence between generated Rust modules and protocol buffers files. My original approach was to write out the FileDescriptorSet, but I modified that to take a similar approach to the Go version before opening this.

I think in the short term it's fine to just write out the FileDescriptorSet to the output directory and have Tonic and whichever other consumers find that useful use include_bytes!. I'll close this pull request and open a new one to implement that approach instead. Getting general purpose reflection capabilities in prost itself probably warrants more thought, and I don't think this short-term tactical approach for getting reflection in Tonic necessarily designs anything out.

[danburkert]

That sounds good to me!