We are only allowed to execute any command once as else we
may disturb the synchrony between CRM and LRM.
The following scenario could happen:
schedule CRM: deploy task 'migrate' for service vm:100 with UID 1234
schedule LRM: fork task wit UID 123
schedule CRM: idle as no result available yet
schedule LRM: collect finished task UID and write result for CRM
Result was an error
schedule LRM: fork task UID _AGAIN_
schedule CRM: processes _previous_ erroneous result from LRM
and place vm:100 in started state on source node
schedule LRM: collect finished task UID and write result for CRM
This time the task was successful and service is on
target node, but the CRM know _nothing_ of it!
schedule LRM: try to schedule task but service is not on this node!
=> error
To fix that we _never_ execute two exactly same commands after each
other, exactly means here that the UID of the actual command to
queue is already a valid result.
This enforces the originally wanted SYN - ACK behaviour between CRM
and LRMs.
We generate now a new UID for services who does not change state
the one of the following evaluates to true:
* enabled AND in started state
This ensures that the state from the CRM holds in the LRM and thus,
for example, a killed VM gets restarted.
Note that the 'stopped' command is an exception, as we do not check
its result in the CRM (thus no race here) and we always want to
execute it (even when no CRM is active).