Run ros_gz_bridge as a Gazebo system instead of a separate process

[azeey]

Desired behavior

Currently ros_gz_bridge provides a ROS node that runs as a separate process. This means, both Gazebo<-> ros_gz and ros_gz<-> ROS incur the cost of serialization and network transport.

It should be possible to provide a Gazebo system that wraps ros_gz_bridge and avoid the Gazebo <-> ros_gz cost since gz-transport topics in the same process use function calls without serialization and hitting the network.

Alternatives considered

n/a

Implementation suggestion

Instead of taking command line arguments, this system would be configured via xml parameters in the <plugin> tag. Alternatively, the configuration can be done via ROS 2 parameters. So instead of setting a config_file, we'd actually set the contents of the config_file as parameters of the node. This has the added benefit of allowing users to add additional topic/service mappings at runtime.

cc @caguero

[mjcarroll]

In terms of a system, this shouldn't need to hook in to any of the Update, PostUpdate or PreUpdate functionality, correct? We should really just have to spin a thread in Configure for the duration of the execution.

[azeey]

In terms of a system, this shouldn't need to hook in to any of the Update, PostUpdate or PreUpdate functionality, correct? We should really just have to spin a thread in Configure for the duration of the execution.

Yup, just a thread started in Configure would do. And terminate and join in the destructor.