We check for the robot state being IDLE and retry that with a very high
timeout by default. This commit also accepts the robot to be in RUNNING
in order to succeed.

Otherwise the robot will reply "Powering on" through the dashboard
interface, but the state will stay unchanged because it is already
idling. Thus, the call will fail (and block very long) while the pure
dashboard call would be succeeding.

This way, for example the setting for keeping remote_control available
stays persistent as requested.

In some circumstances it can happen that we read the first data package
instead of the start confirmation, especially on non-RT systems. In this
case, we can still assume sending start was successful.