Rework SQLCancel logistics to avoid possible races.

[ucko]

Split from #555.

[freddy77]

This smells like potential dead lock to me. In theory in Unix SQLCancel can be called inside a signal handler.

[ucko]

Good point. In that case, I suppose the way to go would be to set some flag on the DBC itself and check it reasonably often from other functions (perhaps by extending the macros around entry and exit); pretty much anything beyond that (even a trylock call) would be unsafe to call from a signal handler. :-/

[ucko]

I've substituted a rework along those lines that crucially also throws in an interrupt handler, and retitled this PR accordingly; the long commit description is

* Split most of its logic into a new _SQLCancel; have SQLCancel itself
  merely set a flag indicating that an _SQLCancel call is in order.
* Automatically check that flag from ODBC_EXIT(_), ODBC_RETURN(_), and
  a new odbc_int_handler (which _SQLAllocEnv registers), by way
  of a new ODBC_CHECK_CANCEL macro.
* Check for cancellation on function entry too, bailing only when
  potentially seeking more results from a freshly canceled query; to
  that end, introduce ODBC_ENTER_HSTMT_OR_BAIL (and a helper
  ODBC_ENTER_HSTMT_EX).
* In _SQLCancel, rely on having the statement's mutex held and add
  HY008 (Operation was cancelled) after clearing other errors.

[freddy77]

This last change looks overkilling. It reminds me of the hero movies in the 80-ish when the hero tried to pull out a bullet using a knife bigger than my forearm and trying not to hurt himself.
Joking aside it looks introducing more issues than what it's fixing. Surely needs more testing. But cancel have to do the cancel, not setting a flag and hoping for the best. Unfortunately too many cases are not tested, at least automatically. Should remove all data pending on same thread and statement? What the behaviour if connection is fully idle? What if the statement is not active? What if there are multiple active statement and you cancel one (MARS, obviously)?
Also I don't like having to poll every second.

[ucko]

I hear you, and had initially looked into finding ways to make immediate cancellation safe.

Alas, there are severe limits on what code potentially called from a signal handler can safely do. ISO is of course particularly strict; Windows is marginally better but still notably forbids any I/O. POSIX is more reasonable, but forbids any mutex operations, even trylock. In practice, temporarily masking signals around lock operations might let trylock (and corresponding unlock) calls succeed safely, but would add major overhead, and AFAICT isn't even an option on Windows (which is too strict anyway).

Incidentally, I see from reviewing that documentation that the flag should have type volatile sig_atomic_t to be fully safe.

[freddy77]

Some working on cancellation, adding new tests... and finding new bugs!