ROS node that runs Gazebo using gz::sim::Server

[azeey]

Desired behavior

There are a few problems with using the gz CLI interface for starting Gazebo from ROS.

• There is no way to include additional plugins that get loaded at startup. For example, once Run ros_gz_bridge as a Gazebo system instead of a separate process #490 is complete, it would be nice to automatically load that plugin without requiring users to include that system in their world files
• Some things we want to do require configuring Gazebo before it starts: Examples:
  • If we want to support package:// URIs in Gazebo, one way of solving it, (1) from Handle model:// path in URI ros/sdformat_urdf#20 (comment), is to add a URI handler to sdformat. But we can't do this without running something before an SDF files are loaded.
  • One idea to make Gazebo Classic to modern Gazebo migration easier is to detect when an attempt is made by Gazebo to load a plugin from gazebo_ros_pkgs or gazebo_plugins and substitute the equivelent plugin from modern Gazebo. One possible way to do this (haven't tested) is to register a handler for the LoadSdfPlugin event. However, this needs to be done outside of a system.
• We don't have a way to load an SDF world file as a string. This would be useful if the SDF file was generated from xacro or something similar. This can be easily implemented in a Node that starts Gazebo using gz::sim::Server.

Alternatives considered

• Add extension points in gz-sim to allow loading plugins at startup. I think this would be nice to have, but I don't think it'd solve all the problems because somethings need to be done outside of a plugin scope.

Implementation suggestion

I propose we implement a ROS node that runs Gazebo using gz::sim::Server. This would make it a lot easier to customize Gazebo in a way that's optimized for ROS users.

[mjcarroll]

I think that this work could also go in conjunction with a standalone executable for gz-sim. Right now, a lot of our parsing/startup logic is in the ruby and gz.cc files, and this could be refactored into a cleaner interface that both the cli tooling and a ROS node could use.