Provide lifecycle servicing

[norro]

The mode manager usually knows the target state/mode and the current state/mode (via mode_inference) of a system or node. Currently we assume, that there is a trivial transition to the target state, e.g, activate to go to active, deactivate to go to inactive.

However, this is not always true, e.g., if actual state is already the target state, or if target state can only be reached with >1 transitions. In order to allow that, mode manager needs to implement some kind of lifecycle service that knows how to get a node from any state to any other.

[chcorbato]

The system modes's extended lifecycle model could be node specific.
For example, a node might be able to transition directly from active status in mode A to active status in mode B, but a different node might need to transition first to unconfigured status.
Actually, maybe this 2nd case should be the default one for node safety.

[norro]

Actually, the 2nd case is the only one currently intended by the ROS 2 Managed Nodes design document. I.e., reconfiguration, which is what we do when switching mode, is only allowed in the unconfigured state.

Currently we ignore this constraint (for now) and re-configure (switching modes) while staying in the active state.

[chcorbato]

Currently we ignore this constraint (for now) and re-configure (switching modes) while staying in the active state.

I think MROS test cases could help analyse whether this (going through unconfigured) is something to enforce, or not, and promote guidelines for handling dynamic node configuration and a reference implementation applying them in navigation2.