transactions are not handled properly in Poco::Data (bug)

• when autoCommit is off, currently the transaction behavior is not entirely correct; it should be as follows:
  • any statement (including SELECT) in non-autocommit mode should implicitly start a transaction
  • one or more statements executed in non-autocommit mode are not in effect until commit() or rollback() is executed on Session

Note: this is a breaking change that modifies the transaction semantics; eg. a statement in a non-autocommit Data::Session will implicitly start a transaction (and lock rows) until commit or rollback is executed from outside.

add POCO::Data::SQLParser (experimental, sql-parser wrapper)

Poco::Data::Statement: unified '?' placeholder support #4365 (moved to separate issue)

add MARS support

Session::open() has no timeout parameter #4366 (moved to separate issue)

make bool Poco::Data::Session::isTransaction() return Poco::Optional
Currently, in non-autocommit mode without explicit Session::begin(), we simply don't know whether we are in transaction or not and we have no control whether we effectively enter transaction or not - the DB will do it automatically in non-autocommit mode and our Session will not know it. To alleviate this situation, SQLParser will be added - not a 100% bulletproof solution, but better than nothing. In order to further minimize unpredictability, bool Session::isTransaction() should return Poco::Optional, so we are explicit about what we know; the downside of doing this is that it will break the code, but a major release is as good opportunity as it gets.

SQLite FTS5 (full text search) #4367 (moved to separate issue)

remove SQLChannel::close() parameter (hides virtual from parent)

move SQLExecutor to a library in Poco::Data testsuite, so it can be used by all back ends to achieve as much common behavior as possible/reasonable

• adjust make buildsystem
• adjust CMake buildsystem
• adjust Visual Studio 2022 and 2019 projects (SQLParser needs C++17) cf. VS170 binary names mismatch on ARM #4207

fix Oracle failing ODBC tests #4368 (moved to separate issue)

fix MySQL failing native and ODBC tests @frwilckens

fix My\PostgreSQL failing native and ODBC tests @frwilckens

Poco:Data::ODBC - MSSQL (n)varchar(max) length issue #4324