Reimplemented server response-waiting functionalities inside the methods of move_group_interface

[CihatAltiparmak]

Description

Firstly, this pull request is created in order to solve this issue #2859 . I still have to apply some test such that this PR works for move2_tutorials and so on. I already have tested this PR on rviz but i need to try this part more to see if any corruption occurs for this PR.

I haven't tested computeCartesianMethod, getPlannerParams, setPlannerParams(acutally there is a posibility that i tested getPlannerParam and setPlannerParam implicitly while testing rviz and getInterfaceDescriptions, or else rviz gets stuck related to node spining)

I have removed callbackthread because it's not necessary to yield CPU continuously during move_group_interface to work. Instead of this, i just made a implementation for spinning only when client send a request from move_group_interface. I also have added private node for move_group_interface to handle its client jobs.

I also have to give anonymous node name to pnode_ . I will work on this as well.

I need some review from variable naming to logic.

Checklist

• [ ] Required by CI: Code is auto formatted using clang-format
• [ ] Extend the tutorials / documentation reference
• [ ] Document API changes relevant to the user in the MIGRATION.md notes
• [ ] Create tests, which fail without this PR reference
• [ ] Include a screenshot if changing a GUI
• [ ] While waiting for someone to review your request, please help review another open pull request to support the maintainers

[CihatAltiparmak]

Hello @sjahr , it seems ready, but not ready for merging, i need a second eye. I only spin now when the methods like plan, execute etc. are called instead of spinning during lifetime of MoveGroupInterface instance. But I want to ask a question.

• With my modification, This instance(move_group_interface) cannot be used concurrently like this because of both of two threads will try to spin separately. In old implementation, it seems below pseudo code works. Should we also support to be able to implement codes like below?

  
  move_group_interface = MoveGroupInterface(...)
  thread1[move_group_interface] = {move_group_interface.plan()}
  thread2[move_group_interface] = {move_group_interface.plan()}

thread1.start() thread2.start()