Motivation: These changes are required for P4Runtime to build
successfuly for downstream users who depend on it in their own projects.
This was dicovered while upstreaming P4Runtime v1.5.0 to the BCR, see
bazelbuild/bazel-central-registry#7594.

- Upgrade googleapis and replace the
  switched_rules extension with the new per-language modules
  (googleapis-cc, googleapis-go, googleapis-python, googleapis-grpc-cc).
  The old switched_rules extension only processes use_languages() calls
  from the root module, which breaks BCR presubmit and downstream users
  who don't call it themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

…her Bazel workspace.

Details:
- In Bazel, it is possible and not uncommon that a project builds from its own workspace, but fails to build when depended on from another workspace.
- We have an example project in example/using-bzlmod that we build in our CI script to ensure both direct and transitive builds work.
- Despite this, in bazelbuild/bazel-central-registry#7594, P4Runtime did not build even though our CI script passed.
- The gap: our example project exercises some, but not all @p4runtime targets in a transitive fashion.
- The solution: run bazel build @p4runtime//... from the example workspace to close the gap.
- The proof: I reproduced the issue seen in bazelbuild/bazel-central-registry#7594 in #591.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

…her Bazel workspace.

Details:
- In Bazel, it is possible and not uncommon that a project builds from its own workspace, but fails to build when depended on from another workspace.
- We have an example project in example/using-bzlmod that we build in our CI script to ensure both direct and transitive builds work.
- Despite this, in bazelbuild/bazel-central-registry#7594, P4Runtime did not build even though our CI script passed.
- The gap: our example project exercises some, but not all @p4runtime targets in a transitive fashion.
- The solution: run bazel build @p4runtime//... from the example workspace to close the gap.
- The proof: I reproduced the issue seen in bazelbuild/bazel-central-registry#7594 in #591.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

…her Bazel workspace.

Details:
- In Bazel, it is possible and not uncommon that a project builds from its own workspace, but fails to build when depended on from another workspace.
- We have an example project in example/using-bzlmod that we build in our CI script to ensure both direct and transitive builds work.
- Despite this, in bazelbuild/bazel-central-registry#7594, P4Runtime did not build even though our CI script passed.
- The gap: our example project exercises some, but not all @p4runtime targets in a transitive fashion.
- The solution: run bazel build @p4runtime//... from the example workspace to close the gap.
- The proof: I reproduced the issue seen in bazelbuild/bazel-central-registry#7594 in #591.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

…her Bazel workspace.

Details:
- In Bazel, it is possible and not uncommon that a project builds from its own workspace, but fails to build when depended on from another workspace.
- We have an example project in example/using-bzlmod that we build in our CI script to ensure both direct and transitive builds work.
- Despite this, in bazelbuild/bazel-central-registry#7594, P4Runtime did not build even though our CI script passed.
- The gap: our example project exercises some, but not all @p4runtime targets in a transitive fashion.
- The solution: run bazel build @p4runtime//... from the example workspace to close the gap.
- The proof: I reproduced the issue seen in bazelbuild/bazel-central-registry#7594 in #591.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

Motivation: These changes are required for P4Runtime to build
successfully for downstream users who depend on it via the BCR.
Issues were discovered while upstreaming P4Runtime v1.5.0 to the BCR
(bazelbuild/bazel-central-registry#7594) and when adding Bazel 9
support.

Dependency updates:
- Upgrade googleapis and replace the switched_rules extension with the
  new per-language modules (googleapis-cc, googleapis-go,
  googleapis-python, googleapis-grpc-cc). The old switched_rules
  extension only processes use_languages() calls from the root module,
  which breaks BCR presubmit and downstream users who don't call it
  themselves.
- Upgrade grpc 1.68.0 -> 1.76.0, protobuf 29.1 -> 33.5,
  bazel_skylib 1.7.1 -> 1.9.0, rules_go 0.59.0 -> 0.60.0,
  re2 -> 2025-11-05.bcr.1.
- Remove rules_proto and gazelle deps (no longer needed).
- Load proto_library from @protobuf//bazel:proto_library.bzl instead
  of the deprecated @rules_proto//proto:defs.bzl.

CI coverage gap fix:
- Our example project in bazel/example/using-bzlmod only exercised some
  @p4runtime targets transitively, allowing build issues to slip through.
- Fix: run bazel build @p4runtime//... from the example workspace.

Bazel 9 support:
- Remove the <9.0.0 upper bound from bazel_compatibility.
- Update .bazelversion to 9.0.0.
- Add --incompatible_autoload_externally=+cc_library,+cc_binary to
  .bazelrc files. Bazel 9 removed native C++ rules from the global
  namespace; this flag restores the autoload. It is a no-op on Bazel
  7/8. (Workaround for two gRPC 1.76.0 bundled files that still use
  native.cc_binary / native.cc_library; can be dropped once a fixed
  gRPC BCR release ships.)
- Update CI to test on Bazel 7.x and 9.x.

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>

cc @chrispsommers @matthewtlam @Eshaan-byte

This fixes p4lang/p4runtime#572

---------

Signed-off-by: Steffen Smolka <steffen.smolka@gmail.com>