Prevent transition events from being dispatched multiple times

Here is the associated patch.

Although the tests have passed, this patch would prevent the post transition subscribers to known the initial state of the transition which could break some existing listeners like OrderEventSubscriber::onOrderPostTransition in the commerce_order module.

@Aerzas: I think the main issue here is that you're saving the order from a postTransition, and that is bad practice... Because the post transition event is dispatched on postSave(). Saving an entity right after it was saved is a bad idea...
Also, this would conflict with the patch from ✨ Allow same From/To state Fixed .

@jsacksick I get your point but it seems realistic to programmatically update an order with further information once a transition has passed.
- Using the preTransition to avoid saving the entity twice could be too optimistic as the transition could still fail and some processing like sending emails cannot be reverted.
- We could listen to the entity update hook or event (like OrderEvents::ORDER_UPDATE), as the entity update is dispatched after the postTransition is resolved, and compare the original entity state, this would produce the same result but it seems less optimized to listen to all update events to catch a single transition. We would still save the entity twice though.
- We could save some data in a separated storage (Drupal state, dedicated table, ...), we could still get it from the entity via computed field if needed. This is probably the intended way but it may feel overkill for very simple updates like storing an email timestamp or third-party service reference.

We prepared a patch to prevent the same transition to be applied twice (provided as a reference) but I guess we'll have to investigate the third option.

@Aerzas: One option you haven't mentioned is adopting the approach from the payment order updater which would consist in "queuing" the update for after the response is sent, via a destruct() method. The idea would basically be to store in a static property the IDS of orders to update on destruct, and then on destruct() reload the order, perform the necessary actions and save the order.

@jsacksick That sounds like a good solution indeed, thanks for the tip.
Let's close this issue because the solution should be developed in our custom code base.