Quicker handling of topics with 0-size user_data.

[neil-rti]

This change adds an early test to see: if there is no 'user_data' (size 0) to parse a type hash, then immediately return OK with a zero-init typehash struct. This avoids executing the rest of the function which would return the same end result.

Topics without user_data can appear when ROS2 apps are run on networks that also carry non-ROS2 DDS traffic.
ROS2 uses the user_data portion of the [Pub|Sub]BuiltinTopicData to carry a "typehash=xxx..." string, but non-ROS2 DDS apps are less likely to use this field, resulting in a 0-length buffer of user_data which is passed to parse_type_hash_from_user_data(). This change detects this condition early, and should have no effect on regular ROS2 topics that use the user_data field.

Tested against rmw connextdds, fastrtps_cpp, cyclonedds_cpp on Iron and Jazzy. Code in Rolling is the same as in these versions.

[fujitatomoya]

I think this changes the behavior of this function.

IMO if user_data is NULL, it should return RMW_RET_INVALID_ARGUMENT. but this changes it into returning RMW_RET_OK with user_data_size is zero. I would add test case for this to detect RMW_RET_INVALID_ARGUMENT in the 1st place of this function.

besides user_data_size == 0 is just a one of the valid argument case, that can be processed below. i would not introduce specific if statement here, i am not even sure how much complexity and performance we can save here with doing this.

but non-ROS2 DDS apps are less likely to use this field, resulting in a 0-length buffer of user_data which is passed to parse_type_hash_from_user_data(). This change detects this condition early

if that is the case, i would do this in non-DDS rmw implementation side to avoid calling this function at all. that is the quickest way to process this for non-DDS rmw implementation? i am not really convinced to support this particular case in the rmw_dds_common...

[neil-rti]

I'm not sure why the pointer would need to be checked when the size of the data it's pointing to is 0 -- there's no work to be done in this function, so it should return. If the size is >0 then the pointer should certainly be checked.

The way things are implemented now, if the DDS topic doesn't have a 'typehash=' string in its BuiltinTopicData user_data -- whether that user_data is empty or not -- all RMW's that call this end up assigning a zero-init typehash struct anyway, so there's no new behavior being introduced overall. Having a 'typehash=(corrupted-value)' is still detected and returned as error -- but the RMW implementations will still just assign a zero-init typehash struct to it -- before passing it along for addition to the GraphCache (which I'm not yet clear why this should be handling non-ROS2 topics).

Also, for clarity: this was referring to non-ROS2 DDS topics, not non-DDS rmw implementations. I wish there was a less-confusing way of referring to the different types. Thanks.