This PR was squashed before being merged into the 5.2 branch.Discussion----------[Messenger] Doctrine setup with migrations| Q             | A| ------------- | ---| Branch?       | 5.2| Bug fix?      | yes| New feature?  || Deprecations? | no| Tickets       |Fix#40130| License       | MIT| Doc PR        |This PR reverts parts of#40055.When running these commands, You do need to be in a transaction:- `doctrine:schema:create`- `messenger:setup-transports`- `doctrine:migrations:diff` and `doctrine:migrations:migrate`Commits-------3371e1c [Messenger] Doctrine setup with migrations

This PR was merged into the 5.2 branch.Discussion----------[Messenger] Don't lock tables or start transactions| Q             | A| ------------- | ---| Branch?       | 5.2| Bug fix?      | yes| New feature?  | no| Deprecations? | no| Tickets       || License       | MIT| Doc PR        |I was so sure my PR#40336 fixed the doctrine-messenger issue once and for all. But it had a very silent bug..This has been tricky to debug and find because the `PDO` behaves differently in PHP 7.4 compared to PHP 8.| Scenario | Command | Is executed in transaction | Method that calls `PostgreSqlConnection::getTriggerSql()` || --| -- | -- | -- || A | `messenger:setup-transports` | No | `setup()`| B| `doctrine:schema:create` | No | `getExtraSetupSqlForTable()`| C | `doctrine:migration:diff` | Yes by default, but it can be configured | `getExtraSetupSqlForTable()`PR#40055 fixed scenario C on PHP 8, but that also broke scenario B on PHP 7.4 and PHP 8.In PR#40336 I was wrong claiming:> We don't need COMMIT because the transaction will commit itself when we close the connection.The result was the we removed all the errors messages from the 3 scenarios. But scenario B will produce some SQL that is actually never committed. IE it will silently fail.I've been trying to figure out a good solution to how or when to start a transaction. I tried out@fbourigault [suggestion](#40336 (comment)) but that would be the same fix as#40055.---------------We need a transaction because the SQL includes a `LOCK TABLE`, however, I cannot see a strict need for it. This PR removes `LOCK TABLE` and all transaction juggling. It all seams to work.I would be happy to get thorough feedback on this PR so we can end the chapter of constantly adding bugs to this part of the component.@dunglas, you added `LOCK TABLE` in your initial version of this class in#35485, could you share some knowledge if this is a good or bad idea?Commits-------26061a1 Dont lock tables or start transactions