On the contrary to other DBMS, MySQL supports schemas, but as databases.
Which means that JDBCConnection gets from the JDBC driver that MySQL does
not support schemas and so it tries to access TAP_SCHEMA tables with a
'TAP_SCHEMA_' prefix instead of 'TAP_SCHEMA.' one. Since MySQL does
behave like it supports schemas, JDBCConnection.supportsSchema must be
set to 'true' if the DBMS is MySQL.

Besides, since no schemas are returned by the JDBC driver
(cf DatabaseMetadata.listSchema(...)), the function
JDBCConnection.isSchemaExisting(String, DatabaseMetaData) must always assume
that the specified schema exists if the DBMS is MySQL. This is particularly
important when the existence of 'TAP_UPLOAD' must be checked, because if the
function returns 'false' the library will attempt to create the database/schema
'TAP_UPLOAD' and will obviously fail due to a lack of permissions. Of course,
it means that the TAP implementor must create manually the schema/database
'TAP_UPLOAD' him-/her-self.

The second particularity of MySQL is the quote character for identifiers.
It is a back-quote (`) instead of a double quote ("). To reflect this
difference, JDBCTranslator.appendIdentifier(...) has been overwritten in a new
JDBCTranslator extension: MySQLTranslator.

The translation of all SQL types and mathematical functions have been adapted to
MySQL according to the online documentation. Few tests have been done locally
with a tiny database. This seems to work but further testing should be
performed in order to ensure the stability of this implementation.

See the commit bd621842,
for the first part of the fix (which actually did not really
fixed the problem: connections "idle in transaction" were
still in the database ; the connection being inside an opened transaction,
it generates lock issues in the database in addition of probably taking
some memory resources).

The transaction and Statement were closed too early before.
  - Fetching the row was not possible once the first bunch of fetched
rows was over.
  - The problem of "statement is aborted" preventing the re-use of
a same DB connection was apparently still there, but occurred less often.

  Now, any transaction potentially started in a DB connection is always
closed after one of the public functions of JDBCConnection is called ;
except executeQuery(ADQLQuery) whose the call MUST be wrapped inside a
try...catch block in which DBConnection.cancel(true) MUST be called
in case of error (in order to effectively end any started transaction).

1) [TAP & UWS] ]MAJOR BUG FIX: The abortion of an SQL query is now correctly
implemented. Before this fix, 2 mistakes prevented this clean abortion:
  a/ The thread was not cancelled because the SQL query execution was
blocking the thread. Then the thread could not treat the interruption though
it was flagged as interrupted.
  b/ The function UWSJob.isStopped() considered the job as stopped because
the interrupted flag was set, even though the thread was still processing
(and the database too). Because of that it returned true and the job phase
was ABORTED though the thread was still running.
  NOW:
  a/ TAPJob calls the function Statement.cancel() (if supported) in order
to cancel the SQL query execution properly inside the database.
  b/ The function UWSJob.isStopped() does not test any more the interrupted flag
and returns true only if the thread is really stopped.
  IN BRIEF: It is now sure that a job in the phase ABORTED is really stopped
(that's to say: thread stopped AND DB query execution stopped).

2) [TAP] BUG FIX: When the writing of a result is abnormaly interrupted for any
reason, the file which was being written is deleted.

[TAP] Add Javadoc for all TAP configuration file related classes + Improve the function ConfigurableServiceConnection.getFile(...) + Set the default value of limits/durations/periods to the maximum value if the new maximum value is less than the current default value.

[TAP] Incorrect setting of the backup frequency. The documentation was also incomplete about this property, but also wrong concerning the property backup_mode which is actually backup_by_user.

[TAP] Change the default value for output and upload limits ; only negative value must mean 'no restriction' ; 0 must be a normal allowed value.

[TAP] Add a 3rd possibility to set metadata in the TAP configuration file: give an extension of TAPMetadata having either an empty constructor or a constructor with a UWSFileManager, a TAPFactory and a TAPLog. & Rename function TAPConfiguration.isClassPath(String) into TAPConfiguration.isClassName(String).

[TAP] Add property to add/replace TAP resources & Add the tool function TAPConfiguration.newInstance(...).

[TAP] Auto deregister at servlet destruction the JDBC driver loaded by the library (only in the case database_access=jdbc).

[TAP] Add a new database access method in the configuration file: get a Datasource from JNDI. & Better support of connection pooling (TAPFactory.countFreeConnections() has been removed ; when the creation of a database connection fails with an SQLException, it is considered that no connection are momentarily available...async jobs will be queued and all sync requests will be rejected).

[TAP] Add support for user identification in the configuration file. Besides, each time a property expected as an integer is not an integer, an exception is thrown.

[TAP] Add metadata support in the configuration file. Two methods to get metadata: 1/ Parse an XML file implementing the schema TableSet, and then re-build TAP_SCHEMA in the database, 2/ Get metadata from the database schema TAP_SCHEMA.

TAP: Missing NULL test (if the property JDBC URL is not provided a NullPointerException would have occurred)

TAP+TEST: First steps with the TAP configuration file management (Factory, ServiceConnection, but not yet Metadata) + their JUnit tests + documentation (the html file + configuration file examples)