#524 JumpTimeCallbacks

[balthasarschuess]

Here is my draft for the time jump callbacks feature.
#524

The way it works right now is:

• we register a callback on the clock
• the on change callback is scheduled through the commands interface of either the node or worker
• the callback parameter is typed based on the chosen jump callback condition, it is assumed, that we don't receive invalid callback payload from rcl.
• for worker jump callbacks the payload is additionally given
• we only handle jump callbacks after the clock change (read more in Feature request: Clock Jump Callbacks #524 about why we might want to support pre-jump callbacks)

TODO:

• write some unit tests
• find a concept for clock.sleep_for clock.sleep_until + use_simulation_time

Regarding the /clock subscription with use_sim_time in the time_source module:

• we could consider using a dedicated worker for our time subscription to avoid deadlocks. This would work for the BasicExecutor, as it runs each Worker in a separate thread. However, that is not given for all executors.
• we could directly subscribe to the middleware callback with https://docs.ros.org/en/ros2_packages/jazzy/api/rcl/generated/function_subscription_8h_1aa63a1641e1138b83f882a9322a134adb.html and drive the clock from there.

I was also wondering if we should even schedule clock change callbacks in the executor.
As I am unsure whether the WaitSet/WaitSetRunner has stable message ordering / guarantees, that we won't process an old message, after the clock time changed.
It would be awkward to spin subscription messages from the earlier simulation time, after state was cleared on time jump.