Fully functioning ROS2 port

[mjeronimo]

I've continued the port started a while back on the 'ros2_port' branch. All of the features should be available with this PR, but some work remains.

The following minor improvements are included in this PR:

• Supported 8UC1 and 32FC1 image types for display
• Display message type in Raw view and Plot view Treeview headers
• Add tooltips on the status line for "# of seconds from beginning" and "bag size"
• Pre-populate bag name for the Save dialog (as the Record dialog does)
• Add Ctrl-A/Ctrl-C handling for the plot view (to make it consistent with the raw view)
• Update the status bar correctly when reading large bags
• Reset zoom level when recording so that events fit in the timeline (dynamically updated)

The following issues remain to be addressed:

• Output a message if/when there is more than one type on a particular topic
• Convert the 32FC1 image type to grayscale for display
• Node selection is not working if the node is in a namespace
• Display float[] (string[] currently works)
• The Rosbag2 class assumes a SQL back-end and does direct SQL access. Instead, this should use the rosbag2_py APIs so that it will work with any database back-end.
• There is a hack to make recording work that needs to be removed. Have to figure out a way that we can be recording a rosbag and also display the items dynamically.
• When publishing previously recorded messages, should be able to use the same QoS as when originally published and recorded. To do this, the rosbags will need to save this information first.
• Rosbags could be collected into a single file (tar file, for example). With this port, the 'rosbag' is identified by the containing directory and not a single file.

FYI - This branch started from the 'ros2_port' branch and then rebased to the current master before making the changes.

[dirk-thomas]

The size of the patch (+918 −479 lines) as well as the large number of orthogonal things fixed / changed / ported makes it impossible to review in a reasonable way.

Imo it would be helpful to land changes in separate pull requests:

• separate pull requests for each addressed issue / implemented improvement targeting the master branch (if applicable to ROS 1)
• after all of those have been merged and released into ROS 1 recreate a ROS 2 branch
• create (a) pull request(s) to adapt the code for ROS 2
• follow up with any ROS 2 specific issues / improvements.

[mjeronimo]

@dirk-thomas Sure. I recently asked Jacob about the strategy on a change like this as I know large PRs can be a pain. The proposed approach sounds good to me. It'll be easier to do now that I have it working and can go back and review all of the changes and stage them as you suggest.

@jacobperron If OK with you, I'll close this PR and get going on submitting (lots of) separate PRs for the individual features/fixes as suggested, starting with those changes that are also applicable to ROS1.

[jacobperron]

Sure, having separate PRs for the improvements (not needed for the port) makes sense to me.

For changes strictly to complete the port, I don't mind if it's one large PR or several incremental ones. At least with the former, we can actually run the application and try it out.

[mjeronimo]

Ok, I'll close and continue. Once I get to the ROS2-specific changes, I'll try to balance providing functionality and the associated code review size.