Multiple issues with current implementation of SQLCancel

Current SQLCancel implementation has multiple flaws/not-conformity to the specification. They may or may not be connected to ODBC-463 as too little info is given, but there is the guess that SQLCancel may be the reason there.

Specs say that "In ODBC 2.x, if an application calls SQLCancel when no processing is being done on the statement, SQLCancel has the same effect as SQLFreeStmt with the SQL_CLOSE". But more recent specs version says that SQLCancel does one of 3 things: cancels function running asynchronously on the statement, cancels function on a statement that needs data, cancels a function running on the statement on another thread.
Currently the driver does not support asynchronous. If statement needs data we can only reset that, otherwise we are cancelling execution running in other thread.

Currently SQLCancel tries to acquire the lock on connection, and if that succeeds it releases lock as it is not re-entrant and calls standard method to close the cursor. If does not - then additional connection is created to kill the query on the server.
The problems with this are:
1) After we release the lock nothing really stops other thread to continue execution on the statement if it waited for the lock. That is possible if e.g. moe that one thread working on connection(plus the thread calling SQLCancel). Not sure if in real world it's a probable scenario, but it is possible.
2) Much more probable is that 2 threads may share same statement handle, and the driver isn't really designed for that. We expect that the connection may be shared, but not the statement. A race condition is possible.
3) if the driver kills the query on the server, it does more like what specs define as canceling on connection and not on statement. We are not guaranteed to kill and cancel the right statement. But I less concerned with this one as I guess in real world it's not a big and probable problem. I'm gonna open separate ticket for that to be fixed in next release series.