Switch from protobuf to prost

[Kixunil]

Is your feature request related to a problem? Please describe. Prost has several advantages over rust-protobuf:

• Produces more idiomatic code
• About four times shorter compile time ~30s vs ~2m
• Supposedly more responsive maintainers (this information may be outdated)
• I guess the generated code is less bloated which could shorten compile times down the line even more

Describe the solution you'd like Switch protobuf to prost. Sadly this is a breaking change because a type from protobuf is present in public API (Error).

Describe alternatives you've considered

• Support both and use features to select - bad idea as features have to be additive.
• Support both using generics and use features only to avoid compile time blow up. Is it worth the trouble though?

Additional context I was randomly looking at things that cause long compile times and this is quite big one.

[mxinden]

One advantage I would like to add:

• prost conveniently generates Rust code into target/ without the code having to be checked into git.

In general I have had only good experience with prost. I do agree that, as a library, it is not only worth optimizing for run time, but as well for compile time. As you already noted, the use of protobuf is pretty entangled into the promtheus crate, thus switching to prost is quite some effort. This might as well be a chance to restructure prometheus to use a custom data representation instead of, as it is done today, using the protobuf representation, especially since the Prometheus project moved away from the Protobuf exposition format.

What do others think?

[breezewish]

LGTM.

However notice that Prometheus deprecates the protobuf wire format. So we only do this for compatibility consideration.

[hexfusion]

This makes sense to me currently we are generating rust stubs with buf the output uses prost types. If there was a prost option this support would be seem less. Is here still appetite for making this change?