fix: Avoid C++ toolchain requirement if possible - #2919

fwiw/fyi: we have a CI job that uses bazel-rolling, in case that's helpful.

Also, a fun trick is using FeatureFlagInfo to detect if a toolchain is present. Something like:

def impl(ctx):
  return FeatureFlagInfo(value=str(ctx.toolchains["foo"] == None))
has_tc = rule(
  implementation = impl,
  toolchains = [toolchain_type("foo", mandatory=False)]

has_tc(name="has_tc")
config_setting("is_has_tc_true", flag_values = {":has_tc": "True"})

alias("launcher_maker", actual = select({
  "is_has_tc_true": ...,
  })
)

Adding a dep on bazel_features isn't easy with rules_python's WORKSPACE setup since it doesn't use two levels of macros. Can we add a call to bazel_features_deps to the relnotes?

@rickeylev @aignas Friendly ping on #2919 (comment). I rebased this PR and updated the PR description to explain the motivation - this is needed to get rid of a transitive dependency on C++ of all Java rules.

If we wanted to avoid the bazel_features introduction we can use the rp_config repo and just check if bazel is version 9 or above.

That said, maybe most of our users on WORKSPACE should either migrate to bzlmod or add bazel_features by this time because it is not sustainable to keep backwards compatibility for too long here.

I'd be +1 for asking them to add bazel_features or to introduce a secondary deps macro. Right now we have py_repository_deps and we could add py_repository_deps_setup. What do you think?

Yeah, lets just add a second deps macro. Workspace makes this painful no matter how we cut it. Might as well provide a utility function everyone can use

Is a deps macro better than asking users to instantiate bazel_features directly? In WORKSPACE days, I would have actually preferred the latter since the module is released frequently and a dep macro bringing in an outdated version is a net negative.

I went with rp_config for now to get CI green without further considerations. Happy to migrate this back to bazel_features if you prefer that.