Provide an option to opt-out of compile_well_known_types

[alexkirsz]

This PR adds a compile_well_known_types flag to the Prost toolchain declaration.

By default, for backwards compatibility reasons, this flag is set to True, as this is the current behavior. If this flag is switched to False, the compile_well_known_types option is no longer passed to Prost and Tonic, and the protoc wrapper will ignore types from the google.protobuf package when computing external types, relying instead on prost's own externals handling. Furthermore, the configured Prost types crate will be added as a runtime dependency to all rust_prost_library targets.

We're currently migrating away from our own set of proto rules to rust_prost_library, but our existing code relies heavily on the prost-types crate's implementations of well-known-types, which is the recommended way of using prost. However, the current behavior of rules_rust_prost makes it impossible to wire up properly, hence this PR.

Fixes #2058

[alexkirsz]

@UebelAndre Would love to get a review on this 🙂

[UebelAndre]

Seems reasonable to me! But can you add some usage of this in the tests directory somewhere so it's regression tested?

[alexkirsz]

@UebelAndre I added tests, which are basically the WKT tests but adapted to use prost_types.

In order to allow configuring the compile_well_known_types flag of the toolchain, I added a bool_flag/config_setting combo, and I'm using a transition to set it to False only for the nocompile_wkt test.

I had originally built the test as its own Bazel workspace with its own toolchain, but this made the test setup much more complicated, and also brought more code into the repo.

However, for the transition to work properly, I had to expose the CrateGroupInfo provider from @rules_rust//rust:rust_common.bzl. This is also something we need in our project in order to build transitions over rust_prost_library, so I think it makes sense to expose it.

[UebelAndre]

Perfect! Thank you!

[UebelAndre]

Sorry I got to this so late, looks like there's a conflict. When I went to resolve it though I had one question which I would love your insight on!

[UebelAndre]

Why explicitly add prost_types in this case?

[alexkirsz]

The code-generated library will now depend on prost-types, so I'm adding the dependency here. Since the user will already have provided a prost-types dependency as an argument to the toolchain, I felt it more consistent to automatically add it to the runtimes for them, instead of asking them to provide it again in the runtimes themselves.