Unify LifecycleNode and Node

Description

Currently rclcpp_lifecycle::LifecycleNode and rclcpp::Node are two distinct classes that both implement the common node interface, but LifecycleNode exposes the lifecycle management features. It would be nice to have a common interface that exposes flexible controls for using lifecycle capabilities or not.

I think that if we were to merge the interfaces together, it would be nice to have it be completely runtime configurable. It seems like there are 3 possible configurations. To expose all 3 of these behaviors, maybe we could expose the following ros arg or special ros parameter (similar to use_sim_time) with 3 different values. Let's call this argument/parameter lifecycle.

1. lifecycle=manual: Current LifecycleNode behavior: expose publisher and services, and don’t auto transition.
2. lifecycle=none: Current Node behavior, but with “auto-transition”: don’t expose publisher and services, and call any configure and activate methods as if they are part of the constructor, and deactivate and cleanup methods as if they are part of the destructor. If the configure or activate methods fail, just fail the constructor. Maybe we would want to consider that if the node transitions itself out of active killing the node, but that might be too implementation dependent.
3. lifecycle=auto: Current LifecycleNode behavior, but with auto transition. You may want the convenience of having the configure and activate transitions on startup and deactivate and cleanup methods on shutdown, but you also want to be able to control the state transitions externally. This could be important because I have seen some LifecycleNodes be written to automatically deactivate themselves on errors, or to fail to configure or activate in the first place depending on conditions.

Motivation

Some people swear by ROS 2 lifecycle and encourage making everything use LifecycleNode. Others don't want the additional complexity and failure points introduced by LifecycleNode, and would rather manage lifecycle using different systems or abstractions. This puts library maintainers in the difficult position where they can either implement one, or implement two versions of their nodes: one lifecycle and one not. If they don't implement one, then lifecycle users may look to put that code in a wrapper or fork it to implement lifecycle, and non-lifecycle users are forced to add lifecycle management code to their project when they wouldn't otherwise (or fork and remove lifecycle). This creates additional friction between libraries and users. A unified, runtime-configurable API would give everyone what they want with no burden on library maintainers.

Design / Implementation Considerations

We may want to merge the rclcpp_lifecycle package into rclcpp. Although this change doesn't necessarily need to affect LifecyclePublisher for example, unless we take on merging all managed entities.

Additional Information

https://discourse.ros.org/t/all-nodes-as-lifecycle-nodes