feat: re-export prost

[yjhmelody]

The following code is very common:

    let mut buffer = Vec::new();
    let metrics_set = prometheus_client::encoding::protobuf::encode(&state.registry)?;
    prost::Message::encode(&metrics_set, &mut buffer)?;
    Ok(buffer)

But we need to import prost crate

[cratelyn]

is there any reason why you cannot also depend on prost? exposing these types in the public interface of this crate introduces a worrisome footgun with respect to semantic versioning: updating this crate's version of prost would be a breaking change.

doing this would mean that this library would need to pin itself to a particular version of prost, and would in turn be prescriptive about what version of prost users of this library to a particular version as well.

there's some discussion about this on the rust forum here: https://users.rust-lang.org/t/semver-behavior-for-dependency-changes/73665/2

If you bump the version of public dependency (i.e. of something which appears in your API), however, that's the different story. In general, this change would be breaking, so you have to bump your own version too.

[mxinden]

Unless this is recommended by the Rust project, I would prefer not to re-export crates in our public API, for the sake of simplicity. In this particular case especially, as I would prefer to get rid of prost.

#162 (comment)

[mxinden]

updating this crate's version of prost would be a breaking change.

Unless I am missing something, bumping to a breaking version of prost is already a breaking change for this crate.

See e.g. prost in our public API:

https://docs.rs/prometheus-client/latest/prometheus_client/encoding/protobuf/openmetrics_data_model/struct.CounterValue.html#impl-Message-for-CounterValue