Better error handling

[volmedo]

Egress tracking is a complex interaction between the etracker service and a storage nodes that has an asynchronous part in the form of the consolidation process. The asynchronous nature of consolidation makes reporting errors trickier. Additionally, consolidation can fail on a full batch, but also only on some receipts.

This opens the door to many edge cases that we'll need to handle properly, given the importance of the process (that is, there is money involved).

Things that need to happen within the context of this issue:

• Proper handling of errors when processing individual receipts in a batch, i.e. populating the ConsolidateOk.Errors field properly.
• Decide whether the egress record should be marked as processed. Depending on the specific error, we might want to keep the record as not processed so that we can retry on a subsequent consolidation cycle.

[frrist]

In the event a Piri node is offline during the time a batch is fetched from it, we should be sure to retry / not consider the record(s) as processed.