Support selective QoS based events

[Yadunund]

This PR adds several new features and fixes bugs while making some big changes:

• GraphCache
  • Allow event callbacks to be registered within GraphCache for local pub/subs.
  • Data structure changes to track and store all details of any entity added to the graph, ie store liveliness::Entity entries
  • Added mechanisms to keep track of event changes and trigger event callbacks.
  • struct TopicStats is removed to simplify nested data structures.
  • Fixed a bug where services and clients were not removed from the GraphcCache when their node is deleted before entities (this behavior is a bug in rclcpp but atleast the consequence is now properly handled).
  • No more lambdas
• QoS events
  • RMW_EVENT_REQUESTED_QOS_INCOMPATIBLE: We support it but this will never be triggered since there are no QoS incompatibilities in zenoh.
  • RMW_EVENT_SUBSCRIPTION_MATCHED: A match is reported when a sub is added to the graph and there are other pubs with the same topic and type. QoS does not need to be checked for same reasons as above.
  • RMW_EVENT_OFFERED_QOS_INCOMPATIBLE: Supported but never triggered as stated above.
  • RMW_EVENT_PUBLICATION_MATCHED: A match is reported when a pub is added to the graph and there are other subs with the same topic and type. QoS does not need to be checked for same reasons as above.
  • QoS compatibility checking was also updated to produce a warning for TRANSIENT_LOCAL pub and VOLATILE sub durabilities. All other combinations are COMPATIBLE to reflect zenoh protocol's behavior.
• Liveliness tokens published now embed zenoh session id, unique id of the entity within the session and the unique id of the node. If the entity is a node, this id is appended twice to keep the number of segments consistent. This allows
  • Uniquely track any entity in the system with a combination of zenoh session id, node id and entity id.
  • Mapping changes to the graph cache to events.
  • Uniquely track two nodes with the same name from the same session (ie load two talker nodes into the same rclcpp_components::ComponentManger
• rmw_X_data_type_t
  • No longer inherit EventsBase 🎉
  • Pub & Sub data types now store an EventsManager class. (There are no events defined for services and clients in rmw/events.h.
  • Sub, Client & Service data types store a DataCallbackManager class. (Publishers do not need to trigger any callbacks).

Testing

Matched events

Follow instructions to run matched_event_detect from demo_nodes_py: https://github.com/ros2/demos/tree/rolling/demo_nodes_cpp#matched-event-detect

Note: I'm seeing some flaky outputs from demo_nodes_cpp executable and I think its coming from PublisherBase in rclcpp.

Nodes with same names from the same zenoh session

Save this text into a python file, source ROS 2, and execute it

import rclpy
from rclpy.node import Node
from rclpy.executors import SingleThreadedExecutor


class myNode(Node):
  def __init__(self):
    super().__init__("my_node")

def main(args=None):
  rclpy.init(args=args)
  node1 = myNode()
  node2 = myNode()
  executor = SingleThreadedExecutor()
  executor.add_node(node1)
  executor.add_node(node2)
  executor.spin()

if __name__ == "__main__":
  main()

In a second terminal run ros2 node list. You should be able to see two /my_node nodes. Without the changes here, this would not be the case as the GraphCache was only capable of handling a singe node name from the same zenoh session.

$ ros2 node list
WARNING: Be aware that there are nodes in the graph that share an exact name, which can have unintended side effects.
/my_node
/my_node

Incompatible QoS

The nodes in ros2/demos are not relevant here since Zenoh does not have the same QoS behaviors as DDS and hence the logic in the executables does not apply.

Future work

• Implement incompatible type events (I started on this but realized the PR is getting too big so will save that for later)

[Yadunund]

Will merge commit ( and not squash since commits may be helpful when reviewing) this into #103 and update the PR description there with what I wrote here so that there is 1 big PR to review and not 2 since this PR rewrites a lot of the same code.