Avoid timers to be executed twice in the multithreaded executor

[ivanpauno]

Fixes #1374 by adding a mutex in Timer class, that makes is_ready and execute methods mutually exclusive.

Fixes #1487.

It deletes the old "scheduled timers" mechanism, that has a long history of being error prone.

[ivanpauno]

Round of CI testing everything above rclcpp:

• Linux
• Linux-aarch64
• macOS
• Windows

[wjwwood]

But this breaks the Timer so that it cannot be run concurrently in a reentrant callback group with a multi-threaded executor. I think we're just trading one broken thing for another.

[ivanpauno]

But this breaks the Timer so that it cannot be run concurrently in a reentrant callback group with a multi-threaded executor. I think we're just trading one broken thing for another.

I wouldn't consider that a bug, at most I would consider it a non optimal approach to the problem. Though really, I'm not sure if allowing to execute timer callbacks reentrantly is a good idea at all, but maybe it is (?).

On the other hand, #1487 is definitely buggy behavior.

But yes this PR isn't really "the right fix" as you can actually block another worker thread that took the same timer (ideally, if we would consider that reentrant execution of the same executable is not a good idea, a worker thread would never take the same executable than another and thus it wouldn't be blocked), but I don't see an easy solution here without major surgery of the executor code (and I'm not sure what that would be).

[fujitatomoya]

But yes this PR isn't really "the right fix" as you can actually block another worker thread that took the same timer

we cannot expect how long user callback takes. if user callback takes 5 seconds and if other threads are scheduled to execute the same timer (I think this is probable), these threads will be blocked for 5 seconds just waiting on the GenericTImer::execution_mutex_. in this case, executor cannot dispatch and process the other executables. (related to https://github.com/ros2/rclcpp/pull/1328/files#r499131414)

[wjwwood]

in this case, executor cannot dispatch and process the other executables

This is exactly the reason I came up with callback groups originally, because otherwise, when using a multi-threaded executor, the user would always have to synchronize their callbacks and that would lead to most threads in the pool just waiting on one of those mutexs, even though other things could be done.

[ivanpauno]

Alternatively #1516 also fixes the issue.

[ivanpauno]

Closing in favor of #1516