@emersonknapp I've made initial implementation for the jump functionality with registering callbacks.
However I haven't added any unit tests for it yet.
Could you please take a look on my implementation and comment if you have any concerns or suggestions?

Overall the approach to jump handlers looks fine - is it mostly copied from rclcpp::Clock?

One thing I have realized, is that:
jump should trigger the callbacks for arbitrary time jumps, and bust the queue in the Player. This probably needs new functionality in the Reader API to seek as well. However, "play_next while paused" shouldn't actually need all of that.

I know that "play_next" feature was a priority of yours, let me know if you have a less heavy approach you want to implement first - maybe jump(callbacks=false), so that we don't have to incur all that overhead for just fast-forwarding to the next message timestamp.

@emersonknapp I wouldn't say that it's mostly copied from rclcpp, but rather have similar approach and design.
I've looked on the implementation of such callbacks mechanism in rclcpp and it turns out it's over complicated. It's diving deep on rcl layer and most of the code written on "C". I adopted some data types from rclcpp and made my own lightweight implementation which should better satisfy our needs and to be more clear for understanding.

WRT to the new reader API for arbitrary seek. Yes it would be nice to have such extension. Although I thought about that it would make sense to implement this feature for sequential reader first. Not sure yet how we will advance in time. May be just reading out messages and skipping them until we will found required timestamp. It could be just straight forward temporary workaround without adding new API to the reader.

And I agree that it make sense to implement this feature with multiple iterations and PRs by adding some essential functionality to unblock development for another features as "Play next in pause".

I think that current API and implementation should cover dependencies for "Play next in pause" feature.

Not sure yet how we will advance in time. May be just reading out messages and skipping them until we will found required timestamp. It could be just straight forward temporary workaround without adding new API to the reader.

Yes, I think this would be a good first implementation. For "go backward in time" - maybe "reopen the bag at the beginning and read messages until the required timestamp". I have a feeling that this will run into performance problems quickly - but at least it would get the feature in front of people to complain about the performance :)

I think that current API and implementation should cover dependencies for "Play next in pause" feature.

OK! I just wanted to make sure you didn't feel like this feature was blocking you from getting to the one you really wanted to do.

Closing this PR as wouldn't merge since we've split implementation on #754 and #775