ROS Time Update is Suboptimal

[DavidPL1]

DavidPL1/assembly_example#3 had me perform some more in detail analysis of time discrepancies. I managed to fix the issue in 24a6154, but as mentioned in the commit message, I really don't like this solution.

In more detail, the error would manifest like this:

* step 0:
 - internal time is 0
 - ros time is 0
 -  no issues 
 - On end, time is incremented to 0.001 and is set by ros::Time::setNow
 - additionally the clock publisher publishes the new time
 - ros time is now at 0.001, but the clock message delivery is pending

* step 1: 
- internal time is 0.001
- (intra-node) ros time is 0.001
- no issues
- On end, time is incremented to 0.002 and is set by ros::Time::setNow
- additionally the clock publisher publishes the new time (not sure what exactly happens within the publisher)

.
.
.

* step 10:
- internal time is 0.010
- (intra-node) ros time starts at 0.010, but along the way gets "updated" to 0.001
- mujoco_ros_control notices ros time is earlier than last time (was 0.009) and performs a reset
- Pending MoveIt goals get preempted
- time gets incremented to 0.011

This repeats occasionally

Interestingly, this only happened sometimes but every time with a notable offset of at least 3 steps, sometimes more than 10.

I don't like that intra-node step speed is limited by how slow ros updates its time based on message publication (even with the intra-node acceleration of using the shared pointer of a message).
Removing the publish and using the setNow call makes everything faster, but then external ros components will be stuck at time 0, expecting messages on /clock.

@rhaschke do you have any idea if and how we could work around this?