Support proto_library targets in @bazel_tools//src/main/protobuf

[meteorcloudy]

This addresses #28400.

Bazel 9 breaks usage of proto_library targets in @bazel_tools//src/main/protobuf because the BUILD file there loads rules and depends on repositories (like @grpc-java, @com_github_grpc_grpc, etc.) that are not visible from the @bazel_tools repository.

This change introduces src/main/protobuf/BUILD.tools, which will be used as the BUILD file for @bazel_tools//src/main/protobuf. This version:

1. Only defines the proto_library targets, avoiding problematic loads and cross-repo dependencies.
2. Adds alias targets for the language-specific targets (e.g., _java_proto) that were previously defined in the BUILD file.
3. Points these aliases to a dedicated target that fails with a clear and helpful error message, explaining that language-specific proto targets are not available in @bazel_tools and users should generate their own code from the proto_library.

This ensures that users can still depend on the proto_library targets while providing a better experience for those attempting to use the unsupported language-specific targets.

[gemini-code-assist]

Code Review

The pull request effectively addresses the problem of unclear error messages for unsupported language-specific proto targets by replacing deprecation warnings with explicit failures. The use of a genrule to provide a descriptive error message is a significant improvement for user experience, guiding developers on how to resolve the issue.

[fmeum]

This won't provide an immediate benefit as long as Protobuf still depends on all the language rulesets, right?

If we already require folks to migrate their usage of some of these targets, I think that it would be better to move these protos out into their own module that still only provides the proto_library targets. It could be versioned together with Bazel and Bazel could even include a nodep to bump the version of the proto module.

[meteorcloudy]

I think that it would be better to move these protos out into their own module that still only provides the proto_library targets.

Yes, this is just a temporary fix that provides a better error message and makes the proto_library work again in Bazel 9.

I agree moving those to their own module should be the long term solution. But we need to figure out how to setup the modue (or modules?). Do you think we need to create a new github project or we can just publish it from the Bazel repo (pointing Bazel source archive)?

[fmeum]

We could release a module from a subdirectory and could even build a dedicated release archive in CI with just that subdirectory.

[meteorcloudy]

How would the release artifacts be published? On the release page? I'm a bit worried confusing users with normal Bazel releases.

[fmeum]

As we would release together with a regular Bazel release, it could be just one more archive attached to a Bazel release. The Publish to BCR workflow can handle the subdirectory and the source.json template can point to the particular artifact.

[meteorcloudy]

I'm thinking about other stuff in bazel_tools, for example, the C++ launcher binary. Probably need a more comprehensive plan for this. So let's make this change for now to stop the bleed. Filed #28434 to track the bigger issue.