[9.x] Fix afterCommit and RefreshDatabase

[taylorotwell]

Previously, using the RefreshDatabase trait was fundamentally incompatible with afterCommit. This is because the trait is based around the fact that it opens a transaction and rolls it back at the end of the test, never committing it.

This slight modification updates the DatabaseTransactionManager to "ignore" a given transaction when determining if a callback should be executed, since we want the outer transaction to essentially be invisible.

Would appreciate some feedback on if this solves people's problems and / or creates new problems.

Fix #35857

[BrandonSurowiec]

Shouldn't this target 8.x?

[driesvints]

@taylorotwell I think @BrandonSurowiec is correct and we should target 8.x

[taylorotwell]

Hmm, I'm torn - existing users can just use DatabaseMigrations trait instead of RefreshDatabase on 8.x. Let's see if this actually works out on 9.x first.

[BrandonSurowiec]

Hey @taylorotwell I use the LazilyRefreshDatabase trait on my base TestCase, so in my 8.x project it is difficult to switch to DatabaseMigrations. This PR seems to have "worked out" so would you accept a PR to backport this and #42502 into 8.x? I ran into this issue today and would love to delete my workaround.

[reza305z]

@taylorotwell still have this issue on laravel 9.42.2 using postgres as database for testing.

[mpyw]

Still reproduces if the transactions are nested. Please check #48451