Right now, we have 2 major subtrees (or branches) in the BT. The "navigation" part, where we compute paths / controls and have context specific recoveries based on them. The other is the "recovery" part, where we cycle through all our recoveries to get the system back in a good place.

We need to find a way to have the recovery subtree attempt the failed portion (or all) of the navigation task after each to see if they succeed now. If they don't, only then going to the next recovery. This will allow us to only execute recoveries until we can actually navigate again and remove all those other actions that don't assist.

Bonus points if we're able to run that check asynchronously, so that not only do we not execute additional behaviors if we can now navigation, but also preempt a currently executing recovery when it can now navigate to continue immediately. This way if partially through a "spin" motion we get unblocked, we can immediately go in that heading vs going to the extents.

One way to do this on a failure of the subtree is to have a blackboard param flipped to indicate to the recovery subtree who failed. In that case, we trigger async replans / control computations at the same time as recovery actions depending on the param. When we can compute whatever value that couldn't be before, we exit the recovery and re-enter the navigation subtree to continue along.

For computing path, that's easy since the planner server doesn't immediately execute the plan, so we can query a path without actually moving the robot out of its current action. For the controller server, we might have to add a new field to the FollowPath action to indicate whether it should send the computed command to the base or not. That way, we can check if it can compute a control effort without actually sending it to the robot to execute as a check that it is now able to.

CC @naiveHobo in relation to #1855