Support Bazel 8

[rickeylev]

I was trying to run our test with Bazel 8 and have been encountering a variety of problems.

The overall impression I'm getting is that the the core code is working, but various dev dependencies aren't.

Debugging this has been rather tough. Usually this is just a matter of updating some dependencies, but I've yet to find a combination of dependencies that works with both Bazel 7 and Bazel 8.

Issues I've seen thus far:

• WORKSPACE.bzlmod is non-empty. It needs to become empty as WORKSPACE files become no-ops
• gazelle has native.sh_binary references: native.sh_binary reference in def.bzl blocks Bazel 8 integration bazel-contrib/bazel-gazelle#1959
• We need to update rules_bazel_integration_test version to fix some native references.
• rules_cc shenanigans -- it seems that between 0.0.9 and 0.0.14 there have been various changes to how to reference bzl files. This ends up breaking doc building and the bzl_library deps. What we'll probably want to do is stop using cc:defs.bzl and start using the more specific loads instead.
• Some issue with stardoc. Upgrading to 0.7.1 seems to fix it, but the release notes for stardoc say 0.7 requires Bazel 7. This will probably be OK; stardoc is a dev dependency, and only otherwise used via sphinxdocs, which is use-at-your-own-risk.

Various notes:
rules_cc centric:

• rules_cc 0.0.9 can't be used with bazel 8: it lacks some fixes
• rules_cc 0.0.10 can't be used with bazel 6: it has a dep on stardoc 7, which requires (in its MODULE definition) bazel 7+
• rules_cc 0.0.11, 0.0.12, and 0.0.13 can't be used with Bazel 6: it tries to use extension_metadata(reproducible=True)
• rules_cc 0.0.14 might be usable with Bazel 6 (mod graph passes) and relnotes say they restored bazel 6 compatibility
• rules_cc 0.0.14 with protobuf 24.4 doesn't work -- protobuf loads @rules_cc//:defs.bzl#cc_proto_library, which was removed in rules_cc 0.0.14`. This was fixed in protobuf 27.0.
• So basically, we must use rules_cc 0.0.14 and protobuf 27.0 or higher together.

stardoc centric:

• Bazel 6 with bzlmod and stardoc 0.7 is a problem: Bazel will fail during module phase because stardoc requires (in its MODULE) Bazel 7.
• The stardoc 0.7 requiring bazel 7 comes from rules_jvm_external: rules_jvm_external has a use_repo_rule call, which is Bazel 7 only.

rules_java centric:

• rules_java before 8.2.0 and using the remote jdsk can't be used with rules_cc 0.0.14 because of the rules_cc cc_proto_library removal.
• Usage of the remotejdk only appears to be done by our examples with the coverage command.
• rules_java 8.2.0+ fixes the rules_cc issue, but can't be used because of a bug defining an android rule which fails due to some private API being used.
• rules_java 8.2.0 requires Bazel 7.3.2 or higher (MODULE checks bazel version)
• rules_java 8.3.0 works, but:
• rules_java 8.3.0 doesn't support Bazel 6 (MODULE checks bazel version)

proto centric

• protobuf 24 can't be used because of the rules_cc 0.0.14 removal of cc_proto_library
• protobuf 28 is sort of the minimum, but our CI is unhappy with that version because protobuf set -Werror (treat warnings as errors), and the debian jobs then fail due to various warnings when compiling protobuf. Other OSes are OK
• protobuf 29 fixes the -Werror problem, but that version isn't fully released. So 29.0-rc1 is the next available version.
• Alternatively, we could use toolchains_protoc in our dev builds, which should avoid having to compile protoc entirely.

[aignas]

I think we should release 1.0 with bazel 8 support and I think that means that we will have to drop bazel 6, which is reasonable since rules_python 1.0 will have to support the min bazel version until we bump to the next major version.

[rickeylev]

We have basic Bazel 8 coverage in CI now. However, I ran across a couple minor issues in the bzlmod example itself. Fix for that is in #2395

[rickeylev]

Ok, I think we have everything passing with Bazel 8.

The one exception is the tests that BCR itself runs -- when I had BCR run our example with Bazel 8, it failed. But it passed in our CI. I'm not sure what to make of that, as the two looked otherwise identical. Anyways, I think we're covered on our end.