Refactor bazel rules to make the build more hermetic

[alextac98]

Notes for Reviewer

Here are the major changes:

• Switch from specified bindgen executable to rules_rust_bindgen
  • This additionally replaces a workaround with a better system
• Create a new cbindgen rule that will call the bazel-managed cargo and rustc binaries to make the bazel build more hermetic.
• As a part of these changes above, I've updated some bazel module versions to later versions to help with this change

Additional note, these are based on changes necessary for us to integrate Iceoryx2 into our bazel project at Inversion Space. I used that as a testing environment.

Pre-Review Checklist for the PR Author

• Add sensible notes for the reviewer
• PR title is short, expressive and meaningful
• Consider switching the PR to a draft (Convert to draft)
  • as draft PR, the CI will be skipped for pushes
• Relevant issues are linked in the References section
• Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
• Commits messages are according to this guideline
  • Commit messages have the issue ID ([#123] Add posix ipc example)
  • Keep in mind to use the same email that was used to sign the Eclipse Contributor Agreement
• Tests follow the best practice for testing
• Changelog updated in the unreleased section including API breaking changes
• Assign PR to reviewer
• All checks have passed (except task-list-completed)

PR Reviewer Reminders

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

References

Closes #1263
hotfix for #301

[alextac98]

@elfenpiff / @elBoberido ready for review! I was unable to assign a PR reviewer or assign myself as an assignee, so I'm mentioning you here as an alternative

[elBoberido]

@alextac98 thanks for the bazel contribution :)

You need to run clang-format and cargo fmt to make the CI happy.

We'll have the iceoryx2 v0.8.0 release in a few days and we try to limit the changes before the release. We'll have a closer look at it but we will likely only merge this after the release is created. Is your intention to get this into v0.8.0?

Also, if it does not take much effort, could you do a rebase to main instead of a merge?

[alextac98]

@elBoberido all comments fixed! It would be super ideal if we could merge it into v0.8.0, but I totally understand if it is a bit close to release. We were hoping to use a stable release once these changes make it in, but weren't aware there was a release happening so soon.

I also added a hotfix to a bazel rule from a recent change, and tagged it to #301

[elBoberido]

@alextac98 good catch with the header-only library. I would cherry-pick that commit for the release if this PR does not get in. Or you could create a PR with just that commit. It would simplify the work on this PR since the CI will run automatically once a contributor has a merged PR.

[alextac98]

I'll separate it out then to make things faster

[dkroenke]

We need to consider that this potentially break the Workspace build, not sure if want to continue with support on that.
As far as I know: BzlMod is supported from version 7.7 on and enabled by default since Bazel 8 (Workspace disabled). Workspace support will be removed in Bazel 9.

[elBoberido]

At least for the foreseeable future, we need to support bazel 7.1 and also workspaces

[alextac98]

I'll work on making it work for Workspace build as well then! Will likely go past tomorrow's release, so I'm happy to push this off to next release.

[elBoberido]

@alextac98 give us a few days to check if we want to support Workspaces for our 0.9 release.

Btw, since your first PR was merged, the CI on this PR will run each time you push you changes

[elBoberido]

Oh, I forgot to tell you that the CI does not run on draft PRs. You can mark it ready for review and add a [WIP] to the PR title