[ADQL] SqlServerTranslator: bug fix for TOP vs LIMITgrammar. Adding support for math functions, including translations for TRUNCATE and MOD non-standard implementation.

Before correction, if an ADQlObject (e.g. a function or a sub-query) contains
another ADQLObject and that both (i.e. parent and child) are matching in a
SimpleReplaceHandler and are asked to be replaced, only the parent
seemed to have been replaced. However, the child has been replaced, but
in the former instance of the parent ; and so its replacement is not
visible in the final query.

For instance:
if all mathematical functions must be replaced by a dumb UDF named 'foo' in
the ADQL query:
        "SELECT sqrt(abs(81)) FROM myTable"
,the result should be:
        "SELECT foo(foo(81)) FROM myTable"
,but before this correction it was:
        "SELECT foo(abs(81)) FROM myTable".

This function was originally static. Since no other classes benefits of this
static state, this function is no longer static. This might however raise a
small incompatibility for the users of the library which used it.

Before this commit, unsigned integers were also allowed (as for ORDER BY).

Because of a test of the first parameter (non existing for functions
like PI() and RAND()), a NullPointerException was thrown and so
was stopping brutally an ADQL query interpretation.

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).

deals with NATURAL JOINs and JOINs using the keyword USING so that being
supported by SQL Server. Basically, they are translated as a list of ON
conditions.
Warning: This translator is just guaranteed to solve the NATURAL and USING
issue. Support for datatypes conversion and case sensitivity has to be
reviewed. Besides no geometrical function is translated for SQL Server.

in first position. This should be totally harmless and should be conform to
the behaviour of a NATURAL or USING keywords in DBMS.

This is easily possible for concatenations, string constants and User Defined
Functions having a FunctionDef. A new special datatype was needed for
numeric functions and operations: UNKNOWN_NUMERIC. This special type
can not be set with FunctionDef.parse(...) and it behaves exactly like the type
UNKNOWN, except that DBType.isNumeric() returns true (as .isUnknown()).
Thus, while writing the metadata of a result in TAP, nothing changes:
an UNKNOWN_NUMERIC type will be processed similarly as an UNKNOWN type:
to use the type returned from the database ResultSet or to set VARCHAR.
(no modification of TAP was needed for that)

Functions whose some parameters are another function were not correctly
identified: since the inner functions were not yet identified, their type
was UNKNOWN and so it makes the identification of the parent function
much easier since an UNKNOWN parameter is not checked. But, it was a
problem if the parameter occurs to be finally of the wrong type.

(indeed, a Concatenation object has no name).

set.

with a constructor having a Properties object loaded with the content
of the current configuration file.

log message (i.e. event = "TABLE_CREATED").

request which has initiated the job creation. Actually the HTTP request is
generated as before, and then, if a job is created, it is set to the ID of the
HTTP request. This modification aims to greatly help the log analysis.

ID set by the TAP library was replaced by the one of the TAP library. The
consequence was a possible bad logging and since the ID is a timestamp, the
ID of the request was indicating a time posterior to a job creation.

UWS service.

dates with no seconds, but also with no day or month. Representations in
days of year or weeks of year were not possible as well. Check out the
ISO8601Format class' Javadoc for more details.

opened by JDBCConnection.executeQuery(...) because a fetch size is set, this
transaction was never closed.

functions must be casted into NUMERIC. Otherwise Postgres rejects the query.

Can be enabled just by providing a file URI in the TAP configuration file using
the property "examples". It is also possible to add manually a TAP resource
whose the returned name must be "examples" like the new TAP resource is doing:
tap.resource.Examples. This latter take a file URI as the TAP configuration
file does. The referenced file must respect the DALI 1.0 or TAP Notes 1.0
syntax. No check of the file is performed by the library ; it is up to the
author of the referenced file (a XHTML/RDFa file) to write a correct "examples"
endpoint content. Check out the examples provided on the GitHub repository in
the directory examples/tap/examples_endpoint.

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.

by the TAP configuration file in order to add/remove/change some metadata or
to change the output of the TAP resource '/tables'.

function ResultSetTableIterator.nextCol(). The formatting is now performed
in ResultSetTableIterator.formatColValue(Object).

Now, all occurences of ' are replaced by '' in the SQL translation.

format. A ClassCastException was thrown about an impossible cast from String to
Character.

types. The notion of "unknown type" is different in function of the target
object:
  - a DBType and a FunctionDef have an unknown type if their function
    isUnknown() returns true. In such case, the other functions such as
	isNumeric/String/Geometry() will return false.
  - an ADQLOperand (e.g. ADQLColumn) does NOT have a isUnknown() function.
    But if the type of the operand is unknown, its functions isNumeric(),
	isString() and isGeometry() must ALL return true. Otherwise, just one of
	these functions can return true.

[ADQL] Fix a Big Bug reported by M.Taylor and M.Demleitner: in ORDER BY, GROUP BY and USING only regular and delimited identifiers are accepted, not qualified column names.
For instance: "SELECT table.column_name FROM table ORDER BY table.column_name" is wrong. We should instead write:
"SELECT table.column_name FROM table ORDER BY column_name".
"SELECT table.column_name AS mycol FROM table ORDER BY mycol" is also correct.
Of course, for ORDER BY and GROUP BY, it is still possible to reference a column using its index in the SELECT clause.
For instance: "SELECT table.column_name FROM table ORDER BY 1".

when in a table definition (extension of DBTable) no schema is
specified, it was possible to prefix the table name by a fake
schema name ; it was checked at all:
e.g. "SELECT * FROM no_schema.foo".
This is no longer possible: if no schema is specified, no schema
must be used in an ADQL query. But if one is specified, the schema
prefix is optional.

1/ Bad parsing of UDF's parameter type or return type. Database types whose the
name has a space (e.g. 'double precision') were not accepted. These type names
should be accepted according to TAPRegExt.
2/ An error message thrown by the DBChecker has been modified for the cases
the type of a parameter is unknown. Before the returned type was NUMERIC. Now,
it will be 'param' followed by the parameter index (e.g. 'param1').

when the content-type was not exactly 'application/x-www-form-urlencoded'
for normal POST requests, no parameter was read by the UWS/TAP library.
This content-type test has now been modified from a strict equality to a
startsWith test.
(Note: This bug only concerned the form encoded requests,
not the multipart ones)

(merge with branch 'unknownFctType')

in the log output. For that the function UWSToolBox.getParamsMap(...)
had to be modified.

Such value is replaced by NULL while ingesting it into a Postgres
database.