Improve error handling on glim_rosbag deserialization error

[VRichardJP]

It is 100% a mistake on my side, but I tried to use the gnss_global extension using NavSatFix messages instead of PoseWithCovarianceStamped messages as the module expects. Obviously it can't work, but I observed that:

• when using glim_rosnode, there is no error nor warning message explaining something is wrong with the gnss data. The module does not do anything, and I initially thought the gnss module was broken.
• when using glim_rosbag, the program crashes upon deserializing the gnss messages:

>>> [rcutils|error_handling.c:108] rcutils_set_error_state()
This error state is being overwritten:

  'Handle's typesupport identifier (rosidl_typesupport_cpp) is not supported by this library, at ./src/type_support_dispatch.hpp:111'

with this new error message:

  'Fast CDR exception deserializing message of type geometry_msgs::msg::dds_::PoseWithCovarianceStamped_., at ./src/type_support_common.cpp:118'

rcutils_reset_error() should be called after error handling to avoid this.
<<<
terminate called after throwing an instance of 'rclcpp::exceptions::RCLError'
  what():  Failed to deserialize ROS message.: Fast CDR exception deserializing message of type geometry_msgs::msg::dds_::PoseWithCovarianceStamped_., at ./src/type_support_common.cpp:118
[ros2run]: Aborted

However, it is not immediately clear what is causing the issue. The error messages shows the program has tried to deserialize a PoseWithCovarianceStamped message, but we don't know from which topic the data comes from. A log message seems to have been added here for that purpose, unfortunatelly the crash happens right before.

[koide3]

Yeah, I think it should at least show some warnings. I'll check if we can detect mismatch of topic types (by catching an exception, or checking topic info in advance).

[koide3]

Hmmm, it is a bit complicated than I had thought at first because C++ does not support reflection --- there is no way to get the name of a type as a string. rclcpp and rosbag2 only provides topic types as std::string, and thus there is no general way to validate the topic type.

While I added an argument to the constructor of TopicSubscription so that the custom module can provide the message type as a string for type check #160, I want to keep it optional as I don't want to force the user to type the msg type name twice as a type and a string. I'll update modules in glim_ext so that the official extension modules provide basic type check.