Stop throwing exceptions on commit in PHP8+pdo_mysql combo

[ostrolucky]

Q	A
Type	bug
BC Break	no
Fixed issues	#1104

Summary

I didn't go with exception swallowing after all, because it turned out PDO has inTransaction() which works here.

[albe]

FYI: @ostrolucky @greg0ire Seeing an odd "Transaction commit failed because the transaction has been marked for rollback only." now with 3.1.1 on PGSQL - Tests pass with dependency fixed on 3.1.0 and nothing else changed 😬:
https://github.com/neos/neos-development-collection/pull/3311/checks?check_run_id=2141073265#step:10:30 ✔️
https://github.com/neos/neos-development-collection/runs/2134647627?check_suite_focus=true#step:19:19 ❌

I'm not sure why that only occurs with PGSQL and the Behat tests, and also only in the tests of our CMS and not even the underlying Flow Framework:
https://github.com/neos/flow-development-collection/pull/2365/checks#step:10:32

That hints at that it might be very edge-case scenario, but still something behaves unexpectedly different now. I will try to find out more.

[albe]

I spent some time analyzing the cause. See neos/neos-development-collection#3311 (comment) for the steps I did.
One of our migrations we run seems to leave a failed transaction open missing a rollback with 3.1.1
Looking at the code, the only possible explanation I have (so far) is this:
The $wrappedConnection instanceof PDO && ! $wrappedConnection->inTransaction() must match (we use pdo_pgsql, which isn't affected by the bug this fixes so this is a behaviour change) and prevent one transaction from committing. So this creates a discrepancy between started/committed transactions?
Also note how this happens when migrations are run on an already current schema (doctrine:create without marking migrations applied) - so the migration statements are logically failing. So a failing transaction that is not committed at the expected point in time is probably caught somewhere else without a rollback, leading to the "marked for rollback only" transaction error at the next commit()?

Edit: This hardly explains why the same doesn't happen in our Framework tests though, where we also should have applied migrations onto a freshly created schema.

Anyway, the core thing is: The condition right now slightly changes commit behaviour outside of the scope of the original issue (PHP8+pdo_mysql).