[enhancement] Lifecycle Component Wrapper

Feature request

Implement a component manager which provides minimal lifecycle behavior for non-lifecycle nodes "a lifecycle wrapper".

Feature description

I have a use case where I am integrating, externally maintained non-lifecycle nodes with a lifecycle management system. I want these non-lifecycle nodes to be managed using the same mechanisms as my actual lifecycle nodes. I want to accomplish this without modifying the external source code. After some investigation, I decided to use a new component managers to load/un-load these non-lifecycle nodes at the appropriate times.

I had brought this concept up for discussion in this ROS discourse post https://discourse.ros.org/t/launch-wrapper-for-rclcpp-node-to-make-it-a-lifecyclenode/23106 (see discourse link for further design details). The post got a few "likes" but there was minimal discussion. I'm currently taking this as an endorsement of the idea being useful to the wider ROS2 community. Therefore, I will put up a PR to accomplish this over the next few weeks, but I imagine the maintainers may want to discuss as well so I'm opening this issue first.

Implementation considerations

There are a few different ways to implement this feature which come to mind:

• Approach 1: Copy/paste the existing component_manager implementation and make the change in that version renamed as component_lifecycle_manager (or similar). This new class would extend LifecycleNode instead of Node. This approach preserves API/ABI compatibility and is the approach I took in my prototype implementation. However, it means the component_manager logic is duplicated making future maintenance tedious.

• Approach 2: Update component_manager to extend LifecycleNode instead of Node and add a constructor argument to component_manager to enable auto transition behavior. So the component manager would behave as a normal node by default (via auto transitioning) but it would behave like a lifecycle node if the argument was changed. I believe, this approach, preserves API compatibility but not ABI compatibility. It has the benefit of ensuring the core component_manager code is not duplicated, but it becomes interspersed with conditional logic which increases the complexity of the module and therefore makes it hard to maintain.

• Approach 3: Try to refactor component_manager's business logic into a separate library which can be used by both a LifecycleNode and Node version of a component_manager. This approach brakes ABI compatibility but could probably maintain API compatibility if implemented carefully. This approach, would prevent code duplication and potentially allow for further extension of component_manager's in the future but it substantially harder to implement than the first 2 approaches.

• Approach 4: Bring Node and LifecycleNode API's in line in a more direct way (such as rclcpp::Node extending rclcpp::LifecycleNode). This has been discussed in other ROS2 threads and I won't consider it here, unless the repos maintainer wish to actually begin such a large overhaul.

As mentioned in the discourse thread. I implemented a prototype successfully using Approach 1, but I would like to do some experimentation with approaches 2 and 3 before putting up the final PR. Any thoughts or additional suggestions are most welcome.

Start by reading the existing component_manager implementation and the linked ROS Discourse discussion, then compare the proposed approaches for wrapping non-lifecycle nodes. Done means agreeing on an implementation direction and providing a component manager that manages those nodes through lifecycle mechanisms without modifying their external source.