This patch can be used to cancel a trigger operation using the TriggerData Java object. The idea is that, since the method that will receive the TriggerData object can interact with the backend only with such object, the cancel request must be performed thru the TriggerData interface/object itself. So I've added methods to set and get the status of a "aborted" flag for the current request. If the trigger data object has the aborted flag set, than the getResultTrigger method will return a (long) 0, to indicate that the current operation has been aborted. The backend, in the functions.c file, will manage such zero as an abort and discard the current operation.

Step by step the patch works as follows:
1) the internal/TriggerData class now implements such methods using a simple
boolean flag to indicate if the current statement must be cancelled or not.
Please note that there is a utility method to check the conditions on which a
statement can be aborted.
2) the internal/TriggerData class when returning the tuple to apply, simply
returns 0 if the statement has been cancelled. Such 0 is interpreted as a NULL
result in the backend code (Functions.c) and therefore the trigger aborts the
current operation.
3) when asking for a newResultSet on TriggerData, the system checks if the
trigger has already been marked for cancelling the current statement, so that
the returned result set is set read-only. This is not the optimal solution,
since one can get the result set before cancelling the trigger, but in any
case the getTriggerResultTuple will avoid insertions/updates.