A ROS service to reset the Servo status

[AndyZe]

We were experiencing an issue where the arm starts in contact with a table. That initial collision needs to be reset before Servo works. This adds a ROS service to perform that reset.

[codecov]

Codecov Report

Merging #2246 into master will decrease coverage by 0.32%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##           master    #2246      +/-   ##
==========================================
- Coverage   57.73%   57.40%   -0.33%     
==========================================
  Files         326      326              
  Lines       25629    25633       +4     
==========================================
- Hits        14797    14715      -82     
- Misses      10832    10918      +86     

Impacted Files	Coverage Δ
...os/moveit_servo/include/moveit_servo/servo_calcs.h	100.00% <ø> (ø)
moveit_ros/moveit_servo/src/servo_calcs.cpp	60.87% <25.00%> (-0.34%)	⬇️
...ls/include/moveit/py_bindings_tools/gil_releaser.h	0.00% <0.00%> (-100.00%)	⬇️
.../include/moveit/py_bindings_tools/py_conversions.h	0.00% <0.00%> (-86.67%)	⬇️
...s/include/moveit/py_bindings_tools/serialize_msg.h	0.00% <0.00%> (-80.00%)	⬇️
...ove_group_interface/src/wrap_python_move_group.cpp	31.97% <0.00%> (-10.98%)	⬇️
.../move_group_interface/src/move_group_interface.cpp	44.44% <0.00%> (-3.64%)	⬇️
...raint_samplers/src/default_constraint_samplers.cpp	82.90% <0.00%> (+0.36%)	⬆️
...meterization/work_space/pose_model_state_space.cpp	82.99% <0.00%> (+0.68%)	⬆️
moveit_core/robot_model/src/joint_model_group.cpp	61.81% <0.00%> (+2.42%)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 576c39c...ee60af7. Read the comment docs.

[jliukkonen]

LGTM

[AdamPettinger]

I like this. Also can handle something else I have noticed:

Before this PR, nothing resets the status back to normal (NO_WARNING). Meaning if you ever get into a status, you are stuck there until a different (non-normal) status occurs.

Example: If you approach a collision and get the DECELERATE_FOR_COLLISION warning, then back away from the collision, you will still be in the DECELERATE_FOR_COLLISION status (and it's published continuously) even though you may now be fine and in a state I think should have status NO_WARNING.

This PR should at least allow the user to reset that manually. I have thought about resetting the status every cycle after it is published, but this would still cause the problem Andy is having (but would be nicer to the user in situations except for needing to move while in collision)

[tylerjw]

lgtm