Fix exec_with_connection ignoring per-migration use_transaction config

[tyt2y3]

Fixes #3001

• Remove exec_with_connection! macro that unconditionally wrapped all Postgres operations in a transaction
• Inline the into_database_executor() / SchemaManager::new() pattern at each call site (fresh, refresh, reset, uninstall), matching the approach already used by up() and down()
• Move the Postgres transaction for drop_everything into the function itself so atomicity is preserved

[yuriy-yarosh]

Not sure about this.
Only database role/user extension and tablespace ops can not be put into a transaction.

I'm expecting it to tolerate use_transaction() for both apply and rollback ops, disregarding what exact database being used PostgreSQL or MySQL. So, that check is a bit pointless... We may get partial support for transactional DDL in MySQL one day, as well. So it worth respecting, when transaction wrap is explicitly enabled, or explicitly disabled.

[tyt2y3]

Not sure about this. Only database role/user extension and tablespace ops can not be put into a transaction.

I'm expecting it to tolerate use_transaction() for both apply and rollback ops, disregarding what exact database being used PostgreSQL or MySQL. So, that check is a bit pointless... We may get partial support for transactional DDL in MySQL one day, as well. So it worth respecting, when transaction wrap is explicitly enabled, or explicitly disabled.

sorry, I don't quite get the verdict. is the new behaviour in this PR good enough? note that before this change, everything is wrapped in transaction on Postgres which is a bit strange