New phase for handling user updates of world state

[arjo129]

Desired behavior

Currently gazebo has three states when running simulations. PreUpdate, Update and PostUpdate. In #1808, I ran into an issue where plugins have to calculate forces to be applied in the PreUpdate step and the user command system also spawns new vehicles in the PreUpdate phase. This leads to incorrect behavior sometimes as the order in which plugins in the same phase are run is not guaranteed. My current fix involves changing the logic of the plugin to make sure we minimize the effect of unexplained behavior. This however requires that System developers have deep understanding of gazebo. What I would like to propose is to have a UserEdit phase where users can interact with the world prior to having PreUpdate run. This way systems which modify the state of the world don't clash with systems which apply physical forces and new entities will always have forces applied to them before the first physical step takes place. So UserCommandSystem would always spawn objects during the UserEdit phase.

Alternatives considered

• Keeping the status quo: The problem is we cannot guarantee physics behavior of items which have been moved by the user.
• Have a way of specifying the exact or partial order in which each plugin should run thus improving determinism: The cons of this are it would require specialist knowledge of Gazebo and leaves correctness to the end user. It would also likely be harder to implement although it would greatly improve the debugging experience. This option is not mutually exclusive with the proposed approach of a UserEdit phase.

[scpeters]

This leads to incorrect behavior sometimes as the order in which plugins in the same phase are run is not guaranteed.

There is a prototype in #2394 for controlling order of execution for system callbacks. It could be possible to address this by thoughtful adjustment of the system priority values