[10.x] Fix how nested transaction callbacks are handled

[mateusjatenee]

A problem we discovered while working on #48705 was that if you have nested transactions and you add callbacks to them, it's possible some callbacks were mistakenly removed upon failure.

The example @fntneves shared:

DB::transaction(function () use ($thirdObject, $secondObject, $firstObject) { // Transaction 1, level 1
    DB::transaction(function () use ($firstObject) { // Transaction 2, level 2
        DB::afterCommit(fn () => $firstObject->handle()); // Callback 1 for transaction 2
    });

    DB::afterCommit(fn () => $secondObject->handle()); // Callback 2 for transaction 1

    try {
        DB::transaction(function () use ($thirdObject) { // Transaction 3, level 2
            DB::afterCommit(fn () => $thirdObject->handle()); // Callback 3 for transaction 3
            throw new \Exception(); // This should only affect callback 3, not 1, even though both share the same transaction level.
        });
    } catch (\Exception) {}
});

The problem is since we only maintain a $transactions counter that goes up (when a new transaction is added) and down (when a transaction is committed, or rolled back), it's possible to have callbacks from different transactions that are on the same level intertwined.
In that example, callback 1 would be removed as soon as transaction 3 failed, because the first and last transaction share the same levels.

I discussed a few options with Taylor, such as having each transaction hold a unique identifier (uuid or just a counter that only goes up), and he suggested splitting the transactions into "ready" transactions and "pending" transactions. This PR uses the latter. Let me know if you think this makes sense..

Also, thanks @fntneves for pointing that problem on the other PR!
P.S: I was unsure whether to target 11.x or 10.x. There are no contract changes, but behavior changes slightly. Let me know and I can change it.

Pending:

• Fix existing unit tests
• Add unit tests
• Add more integration tests

[mateusjatenee]

This PR indirectly touches on DatabaseTransactions since it uses a different Transactions Manager.

The behavior only differs slightly in the sense that it considers 1 as the base level to execute callbacks (since 0 would be after all transactions ran, but there's a base transaction encompassing everything). I've tested it on an app and it worked just fine, but I think another pair of eyes would be good here.
I also added a few tests for the testing DatabaseTransactionsManager.

[crynobone]

Change to DatabaseTestCase so this will be executed on MySQL, Postgres and MsSQL too

[mateusjatenee]

Good catch. Thank you @crynobone!

[hansnn]

@mateusjatenee I believe this PR fixes an issue that was introduced with this PR. Would be great to get your input on it 🙂