Previously, parsing a ChangeMessage might have resulted in a
StatusChangeEvent as well as a ChangeMessageEvent. Depending on
ordering, the ChangeMessageEvent might have come first and thus gotten
grouped together into a different event group. This was happening for
ChangeIT#restore.
Avoid this possibility by setting the status from ChangeMessageEvent
directly, so the status update is guaranteed to be grouped with the
message that triggered it. If we had other ways of parsing status
updates, this would be less flexible, but really we don't. (And if we
did I might want to keep them fused for this reason as well.)
Change-Id: Ibfa5348c1c6e62b393923454507b4c57d25e6b95
694ea78ba9