ABI/API Compliance Checker in github workflow

Feature request

Feature description

Integrate ABI/API compliance checker in github workflow to check ABI compatibility for every PR to see if the fix can be backported automatically with label.

Background

In principle, all bug fixes should be backported to the supported downstream distributions, precisely because they are fixes. Today, however, this backport decision and process depends entirely on the maintainer's manual effort and judgment, so it happens on a need-to-do or requested basis rather than automatically and systematically. (we can find comments requesting or asking for the backport to released distribution.)
One of the key blockers is that it is not always easy to tell whether a fix is ABI compatible with the released distributions. Currently, for every PR, we (developers and maintainers) check the ABI compatibility by looking at the source code, but sometimes it is hard to tell for sure, and this depends on the developer's skill and experience. (I personally run ABI compliance checker to make sure for this.)
We can also see cases where community developers hit a problem on a released distribution, spend time debugging it down to the root cause, and only then discover that the fix already exists on the rolling/development branch but was never backported. They then have to request the backport themselves. This is a waste of effort for everyone involved.
To avoid this burden and keep the high quality of ROS distributions, it would be nice to have an ABI compliance checker automatically run against every PR, so that we can know whether the fix is ABI compatible via a tag or label provided by the workflow. Making this process more automatic and systematic would save significant time for maintainers, developers, and users alike.

Note

This ABI Compatible or Backport-able tag is an additional information for maintainers, says this does not mean we have to backport the fix to already released distros.
Although ABI is compatible, different behavior or significant different user-experience should be avoided breaking the user space.

https://github.com/ros-industrial/industrial_ci/tree/masterv and https://github.com/osrf/auto-abi-checker/tree/master are similar approach against this issue, but they use https://github.com/lvc/abi-compliance-checker that is out dated for a long time. i would suggest we can rely on https://sourceware.org/libabigail/ that looks well maintained and supported.

Implementation considerations

• we can integrate https://sourceware.org/libabigail/ to github workflow. (or any other tools or recommendation?)
• build target branch and PR branch or repo to check the ABI compatibility for every commits.
• new label ABI compatible needs to be introduced and tagged by workflow.

I am creating this issue on rclcpp (because that is where i can find this situation most.) but the following core repositories can have the same ABI checker CI.

• https://github.com/ros2/rcl.git
• https://github.com/ros2/rcl_logging.git
• https://github.com/ros2/rcpputils.git
• https://github.com/ros2/rcutils.git
• https://github.com/ros2/rmw.git
• https://github.com/ros2/rmw_connextdds.git
• https://github.com/ros2/rmw_cyclonedds.git
• https://github.com/ros2/rmw_dds_common.git
• https://github.com/ros2/rmw_fastrtps.git
• https://github.com/ros2/rmw_implementation.git
• https://github.com/ros2/rosbag2.git

flowchart TD
    A[PR / Every Commit] -->|workflow| B[ABI Compliance Check]
    B --> C{ABI Compatible?}
    C -->|Yes| D[Tag / Label]
    D --> E[Code Review]
    C -->|No / Not Required| E[Code Review / Approval]
    C -->|ABI Compatible Required?| A[PR / Every Commit]
    E -->|Mergifyio| F[Backport Process]

after all, i think this will do some good for ROS users, developers and maintainers to accelerate the development process and ROS quality.

Tomoya,