Deactivate command_interfaces when hardware_interface goes inactive

[fmauch]

Following 884 it is clear that the current behavior of deactivating the hardware interface from read/write isn't of much use if all command interfaces stay active. This has been discussed in the last two WG meetings and this issue tries to summarize that discussions. @MarqRazz please feel free to comment or add to this issue.

This is mainly meant as a clear documentation of what should be implemented.

Problem statement

When returning DEACTIVATE from read/write the hardware_interface goes inactive but the controllers
stay active. This doesn't seem like a valid state because the command interface is no longer
connected between the controller and hardware. If this is valid we have issues with the JTC staying
active. When using its PID based velocity control, the desired position it stores can get out of
sync with the robot's current pose when the hardware deactivates. Activating in this state would
cause the arm to jump to the command pose stored in the JTC.

Desired behavior

The obvious request in this scenario would be to deactivate all command interfaces if the hardware
switches from active to inactive. However, imagine a command interface that is used to
recover the robot from a fault state or even to switch the motors back on.

Disabling the joints' command interfaces only also is no proper solution for all use cases, since
IO command interfaces might be used to power certain hardware that should not be able to switch on
while the robot isn't active.

That's why we think that the behavior whether a command interface should stay active or not if the
hardware interface goes inactive should be configurable on an application level. Hence, configuring
this should be available as a parameter / yaml file rather than the ros2_control xacro.

Implementation order

As a first, quick fix the default behavior should be changed (at least for Rolling): When the
hardware goes inactive, all command interfaces should go inactive.

In a second implementation phase it should be possible to define a list of command interfaces that
should stay active as a parameter to the controller_manager. This has to be propagated to the
resource manager, so only the command interfaces that are not on the list are taken down when the
hardware interface goes inactive.

[MarqRazz]

In a second implementation phase it should be possible to define a list of command interfaces that
should stay active as a parameter to the controller_manager. This has to be propagated to the
resource manager, so only the command interfaces that are not on the list are taken down when the
hardware interface goes inactive.

For this to work the hardware will also need to know which interfaces are active otherwise it will likely return DEACTIVATE on the next cycle because it does not know which commands are valid.