bzlmod: Add support for custom go_proto_library compilers

[fmeum]

What type of PR is this?

Feature

What package or component does this PR mostly affect?

bzlmod

What does this PR do? Why is it needed?

These changes are required to allow users of rules_go to use all the custom go_proto_library compilers defined in its //proto package if they provide their own definitions of them:

• Make gazelle and protobuf visible to go_repository targets under
  their legacy WORKSPACE names.
• Expose build_file_proto_mode on go_deps.module.

[linzhp]

Should we support build_directives instead, and configure build_naming_convention and build_file_proto_mode through build_directives?

[fmeum]

This does keep the API smaller, which is good.

It does make it more difficult though to reliably compare multiple definitions for the same repo: Say Bazel module A depends on Bazel module B and both use Gazelle to depend on Go module G. If A and B specify the same go_deps.module attributes for A and B, we can safely use them. But if we allow some kind of free form entry, we could end up in a spot where A and B ultimately consume G in equivalent but slightly different ways (say with differing whitespace).

I'm torn. What do you think?

[linzhp]

Yeah, that's tough. We use build_directives of go_repository rules quite a lot in Uber though, for example, to properly generate Go code from third-party proto files.

Do you think it a better idea to add a attribute for each Gazelle directive?

[fmeum]

As long as we are reasonably sure that almost all use cases can be covered with attributes that are essentially enums, I have a slight preference for that given what I said above. Do you think that's possible or would some attributes need to revert to free form string anyhow?

[linzhp]

There are use cases where we have to use gazelle:proto_strip_import_prefix and gazelle:resolve in go_repository rules. They are free form string, right?

[fmeum]

Good point. I guess it's less about "free form strings" and more about "given a Go module, there is only a single value that makes sense". proto_strip_import_prefix would probably be of that type. I wouldn't expect resolve to occur inside public modules that much, but maybe that's just wishful thinking?

[linzhp]

That's true. Even resolve occurs, it's a fair requirement that they don't conflict: in a build graph, we don't want the same import path to resolve to multiple targets. So yes, "given a Go module, there is only a single value that makes sense" is a good assumption.

How we resolve/override the attributes to the value that makes most sense when conflicts occur?

[fmeum]

That is a good question that I don't have a comprehensive answer for yet.

My first thought was to distinguish between explicitly set and default attributes. If a conflict occurs between two definitions in which every attribute is only explicitly set by one side, we would use that value. If any attribute is set explicitly by two sides and the value differs, we would fail the build. Modules that want to be part of the Bazel Central Registry should thus strive to set as few attributes as possible.