Adapt exception handling in TriggerFanOut

[killenb]

Child of #123

# # # Tickets need rework. See comments # # #*

The TriggerFanout uses a transfer group and had to do exception handling on its own because the transfer group is replacing the transfer, which was that part that was decorated.

With the new scheme this is not necessary. The decorators are on preRead() and postRead(), and these are called by the transfer group. In addition the transfer is not re-tried by the exception handling any more, which would not work with a transfer group. In the new scheme

• the first transfer completes with DataValitity::faulty
• the following read blocks in preRead(), before the transfers are started

Hence, no special handling is needed in the TriggerFanOut

Task:

• Remove all exception handling from the TriggerFanOut
• Run the tests with the latest released version of DeviceAccess (or a version if the master which does NOT contain Add readTransfer() etc. DeviceAccess#117 yet)
  • Write a follow up ticket which tests are now failing. They should work again after Proper implementation of RecoveryAccessor read operations #138 has been implemented.

Notice: This ticket will break the tests in the master until #138 is implemented (which ChimeraTK/DeviceAccess#117 does as well)

[killenb]

Actually, this implementation might not be so bad. It does not harm at least, and might be an easier (but not so clean) solution to a transfer group which does this. It will be needed because the exception handling decorator cannot guarantee that only values with valid version number are going through in transfer groups. It either has to be handled here or in a special ExceptionHandlingTransferGroup.

[killenb]

The only solution I see at the moment is:

• The ExceptionHandlingDecorator needs to know if its in a transfer group (currently only the outermost decorator knows)
• In TransferGroups not recovery is tried but the exception goes through
• An ExceptionHandlingTransferGroup catches the exception and re-tries the whole read(), incl. pre- and postRead().
• The TriggerFanOut uses the ExceptionHandlingTransferGroup and does not special exception handling itself.

[killenb]

The exception handling has been adapted so the TriggerFanOut does not need to know about decorators if the TransferGroup. The TransferGroup is just working correctly with ExceptionHandlingDecorators.

All exception handling has been removed from the TriggerFanOut.

Case closed.