Upgrade bazel rules_* and GRPC dependencies

[flyingsilverfin]

What is the goal of this PR?

In order to use the latest Bazel and GRPC versions, we have to upgrade the various rules_<lang> dependencies during the upgrade of grpc dependencies. We also replace stackb_rules_proto (https://github.com/stackb/rules_proto) with rules-proto-grpc (https://rules-proto-grpc.com/en/latest/).

What are the changes implemented in this PR?

• Upgrade bazel-distribution to the latest, and match the rules_<lang> versions declared there
• Note: this allows using a hermitic python toolchain declaration in the WORKSPACE
• We upgrade grpc, and replace stackb_rules_proto with rules-proto-grpc. However, to make this setup work with the hermitic Python installation, we apply a patch outlined outlined from https://github.com/grpc/grpc/issues/31892. Without this patch, we can receive errors about missing python headers on some operating systems.
• We remove the installation of bazel_toolchains which were unused (?)

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.

[flyingsilverfin]

Closing due the following findings:

This upgrade required upgrading the grpc build rules to a much newer version. However, the newer version of the stackb rules were tricky to use and didn't appear to work very easily. Instead, this work proceeded with rules-proto-grpc and successfully got typedb-protocol (PR), client-java (PR), factory-tracing (PR), and typedb (PR) to a working state, with the exception of assembling the final distributions.

The java_grpc_library rule provided by rules-proto-grpc are architected as macros that automatically pull in various dependencies via Bazel. See https://github.com/rules-proto-grpc/rules_proto_grpc/blob/7064b28a75b3feb014b20d3276e17498987a68e2/java/java_grpc_library.bzl#L26.

These dependencies are Bazel, not Maven dependencies. However, in order to build TypeDB's zip distributions, as well as deploy the Java client, we must provide maven coordinates for every java library we depend on. Because rules-proto-grpc does not depend on these repositories via Maven, our assembly rules fail.

One 'correct' solution could be to provide a mapping from Bazel targets to Maven coordinates to both the java_deps and the assemble_maven rules in vaticle/bazel-distribution. However, we consider reverting back to stackb simpler, since it produces source Java files instead of compiled JARs, which we can compile into our own java library and control its dependencies explicitly.

We also can gain some efficiency by delaying the Bazel and GRPC upgrade since we will drop Python support for compiling our protocol (after implementing native JNI-based drivers.)