inconsistent error handling of storage errors

[fmoessbauer]

While debugging #495, I noticed that storage exceptions raised by the server are not reliably detected by the client:

• Errors that happen while the client is in file.copy() are not detected, because no error handlers are setup and the zmq connection eventually blocks (deadlocks) as the buffers are full. This can be reproduced by injecting a checksum error in a bmap file in one of the first chunks.
• Errors like a partial write ('storage write' failed! (image write failed: wrote 520885248 out of 4967121920 bytes)) are detected by the client only, hence from server perspective the write was successful, while it actually was corrupted.
• After finished storage writes, the "transmitting" panel in the UI remains open (and a new one is created on the next write). This indicates, that no final (INITIALIZED / CORRUPTED) event is emitted.

I propose to rework the storage API in the following way:

• All checks are performed server side
• The client registers to the server events and raises on error

[chombourger]

thanks for the review of the existing code and proposal. this sounds like a good plan!