Customizable cancellation behavior

[luca-della-vedova]

Currently, trying to cancel a workcell task results in a NOOP if the task is being executed, and removing from the queue if it is not running yet. This behavior is embedded in the workcell orchestrator.

There might be types of workcells that can actually offer cancel a running task, so this should at least be configurable, two possible approaches:

• Add a cancel method to Capability that will let users define a cancellation behavior. https://github.com/osrf/nexus/blob/main/nexus_capabilities/include/nexus_capabilities/capability.hpp

• Allow users to specify a BT that the System / Workcell orchestrator should run upon cancellation.

[koonpeng]

There was an unfinished feature that allows defining post-cancellation behavior on the BT. iirc the reason we ended with that solution is because

• If we stop the current actions asap, it will leave the workcell in a unknown / unrecoverable state. Then we would require a human to manually inspect things that are ok and reset the workcell.
• Cancelling can be very dangerous, imagine a pick and place involving a heavy payload, we need to know if it is safe to release the gripper etc. So I imagine that cancelling would most of the time be a no-op on the capability side.
• We can run the current actions to completion. Then we can assume that the workcell is still in a known state, so then we can have a BT to control how to reset the workcell. If the state is deemed unrecoverable then we should also cancel all queued tasks.

So the current behavior is the just easiest safe solution.