Problem/Motivation
If a database does not support transactional DDL, executing statements that alter the database structure in the midst of a transaction lead to the transaction to self-commit.
In our data processing layer, this is less of an edge case than we may think, especially since when we have started creating tables dynamically and not via the hook_schema() called at installation time.
While PostgreSql and SQLite allow transactional DDL, MySQL does not. In the current PDO MySQL driver we can adjust (=reset) the transaction stack when this happens, because it allows to detect if a transaction is active on the client directly. However, in the to-be mysqli driver this is not possible because there is not such a method - we will have to try and interpret exceptions (if they are thrown).
In both cases, though, this would be reactive rather than proactive.
Proposed resolution
1) Introduce a Connection::executeDdlStatement method that, in case of unsupported transactional DDL, will reflect in Drupal's transaction stack that a commit in an active client transaction occurred and make the necessary adjustments in TransactionManager so that the Transaction objects going out of scope do not try to perform database operations. In other words, after execution of the DDL statement, there is NO Drupal transaction active.
2) Change in the Schema classes the Connection::query calls that execute DDL to use Connection::executeDdlStatement instead.