Emit postFlush events as the very last thing in UoW::flush()

[mpdude]

This PR moves the postFlush event dispatching after final clean-up steps in UnitOfWork::commit().

The idea is that at this time, commit() is "as done as it gets", and it might be possible to call EntityManager::flush() again from event listeners – we'd return from that method on the very next line, and everything would be in the same state if users dediced to call flush() again themselves.

Obviously, infinite recursion is one thing either the ORM or users would need to think about.

The intent is to make it somehow possible for users to have event listeners that get notified e. g. through postPersist to prepare "cascading" changes. These changes could be collected and applied in a postFlush listener, which might then call flush() again.

This sparked off from #10869, where the reporting user is calling flush() even from postPersist – a questionable practice, probably never endorsed but it "somehow worked" until 2.16.0.

⚠️ BC Break: If postFlush listeners inspect UoW state through methods like isSchedulesForInsert or getEntityChangeSet, this information will no longer available with this change. → Maybe we need an additional event?

[alexander-schranz]

This would also solve: #8695

[mpdude]

Probably this needs to be a new event for BC reasons.

We also need to think about transaction boundaries: Should the second round of flush() (that’s what we want this event for, right?) happen within the current transaction?

[dmaicher]

We also need to think about transaction boundaries: Should the second round of flush() (that’s what we want this event for, right?) happen within the current transaction?

For my use-case ideally everything should be transactional as a whole. But I guess I could also work around this myself by wrapping everything in a transaction inside the listener or so.

[mpdude]

Closing for the time being - the current idea is to make it possible to call flush() also from event listeners. See #10982.