Allocate a message with type only known at runtime

Feature request (or request for a pointer on how to do it)

Allow allocation of message with unknown type at compile time.

Feature description

This issue crops up in development of rosbag2: Imagine a user created a bagfile on a machine with a certain rmw "A" and passes it to another user who wants to play it back with a second rmw "B". To allow fast writing, we need to store the messages in their serialized form, hence we need to potentially convert between the serialization format of "A" and "B" (of course, to convert both rmw's need to be present).

To allow conversion between arbitrary formats, the default interface will be to take a ROS 2 message in its serialized version and convert it to a standard ROS 2 message. In essence, this requires a call to rmw_deserialize.

Here is the problem:

rmw_deserialize takes a zero-allocated message of the correct type.

https://github.com/ros2/rmw/blob/3b9ea0f66feb161d5872cfde0317dd8280a8b91a/rmw/include/rmw/rmw.h#L250

This is no problem if we know the type at compile time. Let's say it's a std_msgs::msg::String so we just do

std_msgs::msg::String string;
rmw_deserialize(serialized_message, &load_typesupport("std_msgs/String"), &string)

where load_typesupport is some helper function loading the correct typesupport via Poco.

However, if we don't know that it's a std_msgs::msg::String at compile time, we can't write the first line above. In the rosbag2 scenario above, we clearly cannot know the message types at compile time, we only know the type identifier (and therefore the typesupport) when we see the bagfile.
Hence our feature request: It should be possible to zero-allocate a message whose type is only known at runtime.

Note that we want to support editing bagfiles with different languages in principle (e.g. python and C++), so we'd need this information for every typesupport.

Implementation considerations

From what I understand, this would require one of two things:
a) Information about the size of the zero-allocated message
b) A function to get a zero-allocated message (i.e. some form of constructor)

Due to name-mangling in C++, it will be very hard to get the constructor symbol out of the corresponding libraries (e.g. libstd_msgs__rosidl_typesupport_cpp.so for std_msgs/String), so b) seems difficult.

On the other hand, this should also be a general issue for C and indeed it seems that rclc - I know it's no official package - adds information of type a) to a new typesupport (?).

https://github.com/ros2/rclc/blob/master/rclc/include/rclc/type_support.h
(used to hand to rcl_take here:
https://github.com/ros2/rclc/blob/51f0743b83f04081dc486f79b22dfbe8b761e7e2/rclc/src/functions.c#L123)

If I am not mistaken, this implies the size information is currently not present in the rosidl_typesupport_t struct. Could this be added?

Fyi @Karsten1987

Start with the rmw_deserialize signature in rmw/include/rmw/rmw.h, then compare the type-support information in rclc/include/rclc/type_support.h and its use in rclc/src/functions.c. Determine the API and cross-language typesupport requirements for allocating a message whose type is known only at runtime. Done means an agreed approach that supports the rosbag2 conversion scenario.