Update tests to V8 VSMYSQL / Update to vsjdbc 12.0.0

[ckunki]

Since 2023-06-02 for version 8.18.1 of Exasol database a Docker image is available on Dockerhub.

The current ticket therefore requests to update the integration tests of VSMYSQL to use version 8.23.0 as latest default version.

Please note sibling-tickets for all JDBC-based virtual schemas.

[ckunki]

Please see ticket linked in IntRef.

[redcatbear]

A flag for more strict checking is set in V8. This breaks compatibility.

[pj-spoelders]

After some research and a few discussions with BC and CK last Friday we've reached the assumption that the virtualSchemaStrictDataTypeCheck database parameter that's set as 1 (true) for Exasol databases starting from v8.x is 'at fault' for these specific tests' failure.

I have confirmed this assumption using the following commands (using confd) to alter this flag in the docker db container:

docker exec -it *<container_name>* /bin/bash
confd_client -c db_stop -A '{ "db_name": "DB1"}'
confd_client -c db_configure -A '{ "db_name": "DB1", "params_add": [ "-virtualSchemaStrictDataTypeCheck=0" ]}'
confd_client -c db_start -A '{ "db_name": "DB1"}'

This makes the 2 failing tests succeed.

Apparently this flag is set to false (0) in v7.1.14 and above. but to true (1) in v8.x onwards.

The ideal fix here, imho, would be to:

• Set this flag to false (0) in V8 as the default, as to not break users' existing virtual schema use.
• Document this database parameter, because it is currently undocumented AFAIK.

[pj-spoelders]

After a lot of discussion and research the preferred solution would be to make the VS correctly detect the Latin1 schema used in both the pushdown and the virtual schema table creation and set the char set to UTF-8 instead of (Exasol) ASCII.

[ckunki]

Investigating Issues and potential changes to VSCJDBC

[pj-spoelders]

As discussed, we'll try to fix the issue in the virtual schemas itself. Doing a deep dive RN.

[pj-spoelders]

So as was decided, the behaviour when it comes to character sets is now simplified,
The target char set is now always UTF-8.
The IMPORT_DATA_TYPES property (and value FROM_RESULT_SET) are now deprecated (change in vs-common-jdbc).