commit cffd2fabb0d5bb855fb0c85ca72acb4df74ffc97
author John Eikenberry <jae@zhar.net> Sun Aug 20 15:51:26 2017 -0700
committer John Eikenberry <jae@zhar.net> Sun Aug 20 16:15:01 2017 -0700
tree 5884d96dd5dbc9fe9f5f32fca9f13599141a3012
parent bc6b56aae0166afb42f1a6efca6118a493802a0c

Fix #195 Handler wrappers deal with errors

TLDR; have the Handler wrappers generate the response packets for the
errors instead of returning the errors.

Errors from the handers was returned up the stack to the request-server
handler call. In cases of errors the packet for the error was then
generated using the passed in packet (the incoming packet).

For file read/write/list operations the incoming packet data (includeing
ID) is put in a queue/channel so that it can be handled by the same file
handling code returned by the handler.

Due to gorouting scheduling, in some cases the packets in the channel
won't line up with the incoming packets. That is the worker that took an
incoming packet with one ID might respond with a packet with a different
ID. This doesn't matter as the reply order of packets doesn't matter.

BUT when this response packet that doesn't match IDs with the incoming
packet system returns an error, it uses the incoming packets ID to
generate the error packet. So the error response would use that ID and
the packet from the queue, once processed, would also use that ID
(because on success  it uses the ID from the packet in the queue).

This patch fixes the issue by having the code that works with the
packets, either incoming or from the queue, generate the error packet.
So there is no chance of them getting out of sync.