bug 7985 Using UncaughtExceptionHandler in TransactionInvokerImpl

bug 7985 Using UncaughtExceptionHandler in TransactionInvokerImpl

when a particular transaction command fails , it is killing the only
worker processing the transaction commands queue.

when the exection is caught log the exception and resubmit the worker

if 10 commands are to be exectuded
while executing 5th command some exception happens
then the execution resumes from 6th command ignoring the 5th command.

Again if 6th command also fails because of some exception,
then execution resumes from 7th command onwards that way it wont result in
infinite loops.

This patch does not try to address transaction failures, only addressing any
exceptions in the commands.

for transaction chain failures, let us say all 10 commands are executed
successfully and submitted to transaction chain, now we wait for
success/failure of each such transaction asynchronously.
Now our pending tx list reads as 1,2,3,4,5,6,7,8,9,10

we may get success response for 1,2,3,6,7 and failure for 5th.
Then pending tx list reads as 4,5,8,9,10.

then the transactions will resume from 8th onwards. Note 4th is not resumed.
This behavior may not be desired as we are trying to resubmit 8th one which
already got executed.
If the transactions are idempotent then it should not be an issue at all to
reexecute the succeded ones.
Now if the 8th transaction is about deleting an entry ,
in its previous run it already deleted it, so this run will fail.

Now for the 4th one we may get a success callback or failure callback.
If we get failure callback , then again 8,9,10 will be reexecuted.

This patch is not addressing this scenario , can be taken up in later
patches with the right design.

Note the difference between command execution and transaction result.
This patch is addressing exceptions in command execution.

Change-Id: I93bba958784637a4752b860d23354506f0bd98bb
Signed-off-by: K.V Suneelu Verma <k.v.suneelu.verma@ericsson.com>