Test eventual consistency of outbox events in the wrong order
This can happen as ID generation is not transactional. We should be immune to it, i.e. we should reach consistency eventually. E.g.:
An entity is created, updated, then deleted in separate transactions, but the delete event has ID 1, the update event has ID 2, and the add event has ID 3.
An entity is deleted, then re-created in separate transactions, but the add event has ID 1, the and the delete event has ID 2.
An entity is updated twice in two separate transactions, resulting in two events with different routing keys, but the second update event has ID 1, and the first update has ID 2.