Add a `MODULE.bazel` in order to support for `bzlmod`

[shs96c]

Is your feature request related to a problem?

In Bazel 6, a new feature called bzlmod will ship. This is like a "package manager for Bazel rulesets", and using it avoids a lot of setup work being need to be done in a WORKSPACE.

Describe the solution you'd like

When run, bzlmod looks for rulesets on the Bazel Central Registry. Once the MODULE.bazel is added to this project, it can then be registered with the BCR, and then people can start using it from the modularised builds.

Describe alternatives you've considered

There are no alternatives at the moment.

Additional context

While there are workarounds to get things working, it would be nice if this was available before Bazel 6 is released, so projects can migrate to using bzlmod ASAP.

[sanjaypujare]

Support for bazel is on best effort basis. You may want to consider contributing this enhancement so it can then be reviewed.

[ejona86]

Because of the integration with BCR, it looks like we may need to be the one to do the last parts of this. And unclear if we'll need a new part to the release process or something. Looks like protobuf is out-of-date and we'll need to have yet-another copy of all our Maven dependencies (seems to replace maven_install).

This is probably all for the best, but will be annoying during the transition and will need some effort to rework.

[shs96c]

You can move the build to use Bazel 6, so you'll only have one version of your maven_deps in the tree (in a MODULE.bazel file). Users of the library won't be impacted by that change.

[ejona86]

You can move the build to use Bazel 6... Users of the library won't be impacted by that change.

If we don't test with Bazel 5, we'll break something. And we'd still need to support the maven_install approach (for Bazel 5 users, and Bazel 6 users that haven't swapped to modules), thus the duplication I noted.

[vorburger]

There IS a https://registry.bazel.build/modules/grpc but it doesn't define @io_grpc_grpc_java and is presumably only for https://github.com/grpc/grpc? I couldn't find any documentation what that module actually provides.

[tmhdgsn]

Has there been any movement on this ? Thanks !

[ah-quant]

Bazel 7 is released now and MODULE.bazel is enabled by default. The release of Bazel 8 will disable WORKSPACE by default and Bazel 9 will remove it. Seems like the perfect time to pick this up again.

This issue is tagged with "help wanted" and I experimented a bit but hit a snag. Working on this probably also needs module support in https://github.com/googleapis/googleapis (there's even already a PR, googleapis/googleapis#855)...

I'm not hopeful that a non Googler can do anything in googleapis. I'm not even sure issues and PRs in that repo are even read. Can you tell us a bit about the situation there or nudge someone into looking at it? (edit I misjudged, commits by external contributors seem to exist. But this probably has to be aligned with internal code and will be quite intricate)

This will probably also affect grpc/grpc#35271

[ejona86]

External contributors should be okay, but yeah, I see even a trivial PR updating a broken link has been languishing. @veblush, do you know who best to poke on googleapis to review PRs?

Googleapis is a severe risk for this item. Its dependency situation tends to take some effort in the best of times, and there's circular dependencies between multiple grpc repos and googleapis that seem will impact this. I see the mention of use_repo; I know nothing about it, but it sounds like we may need it here.