Add support for Zenoh in Bazel builds

[luca-della-vedova]

🎉 New feature

Summary

As per title, there was no Zenoh support for Bazel builds, also adds a CI job to verify that unit tests pass.
The most important (and potentially controversial) change is that the added dependency to zenoh is to 1.7.2 while the codebase was (I believe) targeting 1.5.0.
I tried this out and it seems to work (also can reference green CI in this PR), I referenced the rmw_zenoh bump PRs where indeed going from 1.5.0 to 1.7.1 (there was no 1.7.2 bump) was very straightforward and involved no code change:

• 1.6.1, no diff, only bump dependency tags.
• 1.6.2, Same.
• 1.6.2, Same, with a new config that is not used.

By contrast the 1.8.0 bump was a lot trickier, so tricky that it had to be reverted and done twice!

A rough overview of other changes:

• Add a enable_zenoh bazel flag to the build.
• The enable_zenoh actually changes the value of the GZ_TRANSPORT_DEFAULT_IMPLEMENTATION variable. This might not be strictly necessary but it's a bit confusing when users build gz-transport with enable_zenoh:=true and it doesn't actually use Zenoh unless they also set an environment variable.
• The various changes in the test BUILD.bazel are due to the fact that there are now dependencies on test config files, so they are needed for the tests

Backport Policy

• This is safe to backport to the following versions:
  • Jetty
  • Ionic
  • Harmonic
  • Fortress
• This should not be backported
• I am not sure
• Other (fill in yourself)

Test it

In CI, or locally with:

# With Zenoh
$ bazel test --//:enable_zenoh=true --test_output=errors //...
# Without zenoh, can also omit, or set enable_zenoh to false
$ bazel test --test_output=errors //...

Checklist

• Signed all commits for DCO
• Added a screen capture or video to the PR description that demonstrates the feature
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• Updated Bazel files (if adding new files). Created an issue otherwise.
• While waiting for a review on your PR, please help review another open pull request to support the maintainers
• Was GenAI used to generate this PR? If so, make sure to add "Assisted-by" to your commits. (See this policy for more info.)

Assisted-by: Gemini

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

Backports: If this is a backport, please use Rebase and Merge instead.

[luca-della-vedova]

Discussed at Gazebo Asia community meeting that this seems to be OK and shouldn't break anything

[caguero]

Looking good overall! I just left a few minor comments.

[caguero]

This makes a Bazel build with enable_zenoh=true default to zenoh at runtime, while a CMake build with zenoh enabled still defaults to zeromq (GZ_TRANSPORT_DEFAULT_IMPLEMENTATION is an independent cache variable there). I'd keep zeromq as the default in both build systems so they behave the same, and run the zenoh CI job with --test_env=GZ_TRANSPORT_IMPLEMENTATION=zenoh instead. Same test coverage, less code.

[luca-della-vedova]

I just realized actually, is the purpose of the HAVE_ZENOH just to make gz-transport work regardless of whether zenoh is available or not and, in the future, if Zenoh is widely distributed we can just remove it and compile the support altogether?
If so, I just reverted this change, removed the zenoh_enabled condition altogether in 5a17f7b and did your suggestion of using test_env to set the environment variable, since Zenoh is already available in BCR it will always be built (hardcode HAVE_ZENOH to true in Bazel builds) and users just need to specify the environment variable to choose their transport implementation.
This will cause generally longer build times for gz-transport but at least users don't need to mess with build flags (it can be a bit tricky to keep track of all the build flags needed for every downstream dependency when building large projects).

[caguero]

How about a small comment to keep all Zenoh min versions in sync:

Suggested change

	bazel_dep(name = "zenoh-cpp", version = "1.7.2.bcr.1")
	# Minimum version (bzlmod may resolve higher). Keep in sync with
	# GZ_TRANSPORT_ZENOH_MIN_VERSION in CMakeLists.txt (see #868).
	bazel_dep(name = "zenoh-cpp", version = "1.7.2.bcr.1")

[luca-della-vedova]

9058ccf

[caguero]

Optional: both jobs only differ in the flag value. A strategy.matrix over enable_zenoh would avoid the duplication.

[luca-della-vedova]

Ah yes, nice! cb4209f