Support lifecycle-managed timers in rclcpp_lifecycle::LifecycleNode

LifecycleNode::create_timer() と create_wall_timer() から始め、ここで説明されているライフサイクル遷移の動作と、PR #2261 の設計に関する議論を確認してください。API と遷移状態に関する未解決の疑問をメンテナーと解決します。完了の条件は、ライフサイクル管理のタイマー API について合意され、非アクティブ、アクティブ、繰り返しの遷移、アクティブな状態での作成、失敗した遷移を対象とするテストがあることです。

Description

rclcpp_lifecycle::LifecycleNode does not provide an API for managing timer callback execution based on lifecycle state.

Currently, LifecycleNode::create_timer() and create_wall_timer() create regular rclcpp timers whose callback execution is not managed by lifecycle transitions.
As a result, if an executor is spinning, timer callbacks may run even when the node is Unconfigured or Inactive.

This is not a claim that the existing timer APIs are incorrect.
The issue is that LifecycleNode does not provide an API for opting into lifecycle-managed timer behavior.

This issue proposes the following behavior for lifecycle-managed timers:

Lifecycle state or transition	Proposed timer behavior
Unconfigured	Do not start executing new timer callbacks
Inactive	Do not start executing new timer callbacks
Successful transition to Active	Start or resume callback execution for timers that have already been created
Active	Allow lifecycle-managed timer callbacks to execute
Successful deactivation	cancel() the timer; callbacks already in flight may complete
Successful cleanup / shutdown	Prevent new timer callbacks from starting and clean up the timer

The start behavior for a timer created while the node is already Active, and the behavior when a lifecycle transition fails, are left as open questions below.

Motivation

Applications may need to control periodic timer-based work according to lifecycle state.
However, because LifecycleNode does not provide a lifecycle-managed timer option, each application must implement this control separately.

The ROS 2 Managed Nodes design describes Inactive as a state in which the node is not performing any processing.
The lifecycle_talker demo also uses a regular timer and includes a comment that a future version will add a timer following the same lifecycle management as a lifecycle publisher. This comment provides historical context that lifecycle-managed timers have been considered before.

Inspection of the LifecycleNode implementations in Rolling and Jazzy found that neither branch provides a separate lifecycle-managed timer API.
On Jazzy, I confirmed that callbacks from a regular create_wall_timer() execute while the node is both Unconfigured and Inactive.
This result demonstrates the current behavior of regular timers; it does not imply that the existing API violates an explicitly documented lifecycle contract.

Design / Implementation Considerations

There are three possible API directions to consider.

Add a new API

1. Add separate APIs for creating lifecycle-managed timers.

Change the existing APIs

2. Change the default behavior of LifecycleNode::create_timer() and create_wall_timer() so that they create lifecycle-managed timers.
3. Add an option to the existing APIs for selecting managed or unmanaged behavior.

For now, I propose adding separate APIs.
Changing the default behavior of the existing APIs could alter timer behavior in Inactive without a compile error for existing applications that use auto or rclcpp::TimerBase::SharedPtr.
Adding an option would preserve existing calls, but the same function would provide different lifecycle behavior, requiring readers to inspect the option at each call site to determine whether a timer is lifecycle-managed.
Separate APIs would preserve existing application behavior while making the distinction between regular and lifecycle-managed timers explicit at each call site.

For example, the following APIs could be considered:

create_lifecycle_timer(...)
create_lifecycle_wall_timer(...)

To assess the feasibility of the proposed behavior, I tested a downstream implementation that calls cancel() and reset() on timers in response to lifecycle transitions.
The Jazzy-based tests confirmed that new callbacks did not start while the node was Inactive, callbacks executed while it was Active, and timer callback execution resumed across repeated activate/deactivate cycles.

This validation only establishes the feasibility of the proposed lifecycle behavior.
The actual upstream API names, signatures, return types, and internal management approach remain open for discussion with the maintainers.

PR #2261 proposed separate APIs for lifecycle-managed timers and integration with lifecycle transitions, but it was closed without being merged.
The review raised design questions about whether callbacks should execute before activation under different autostart settings and how a timer created while the node is already Active should behave.

This issue does not request adopting the implementation from #2261 as-is.
Its purpose is to clarify behavior based on lifecycle state and timer creation timing, and to revisit the API design for lifecycle-managed timers.

I would appreciate maintainer guidance on the following:

1. Is lifecycle-managed timer support still desired for Rolling?
2. Which direction would be preferable: adding separate APIs, changing the default behavior of the existing APIs, or adding an option to the existing APIs?
3. If a lifecycle-managed timer is created while the node is already Active, should it start immediately?
4. How should a managed timer behave when a lifecycle transition fails?

Additional Information

Lifecycle-managed timer support for rclcpp_lifecycle::LifecycleNode in Rolling