Use ControllerManager node clock for control loop timepoints

[schornakj]

In the current version of ros2_control_node.cpp, this line (from #520) incorrectly calculates a timepoint that is relative to the time when the controller manager node was initialized, where it should instead use either the actual epoch time for real hardware or the simulated time when running in Gazebo or another simulated context. When a controller plugin publishes ROS messages (for example, when the JointStateBroadcaster publishes JointState messages), it uses these incorrect timestamps in the message headers, which causes problems downstream with TF lookups and perception calculations.

This PR changes the calculated timepoint to be correct relative to the start of the epoch.

This PR also changes the control loop to use the ControllerManager ROS node's clock as the time source instead of the system clock, which allows switching between simulated and real time through the use_sim_time ROS parameter. Prior to the API update the controller plugins used ROS time, so the end result here should be the same as how it was before.

[destogl]

This looks reasonable. Just small thing to clarify.

[destogl]

Should/can we use here simply:

Suggested change

	std::chrono::duration_cast<std::chrono::nanoseconds>(begin.time_since_epoch()).count()),
	cm->now(),

[schornakj]

It's not exactly the same as what you suggested, but I was able to significantly simpify this by storing the update timepoints as rclcpp::Time instead of std::chrono::duration.

[bmagyar]

in general I very much like this but agree with @destogl 's comment.

...also please run precommit at the end ;)

[schornakj]

in general I very much like this but agree with @destogl 's comment.

...also please run precommit at the end ;)

@bmagyar I addressed the feedback and cleaned up some of the very verbose code. I also made sure to run pre-commit!

[destogl]

Thanks for PR and the fast follow-up!