Do not silently drop unhandled obelisk messages

[swansontec]

If the obelisk connection is shut down,
fire the error callback on any pending requests.
This gives the client a chance to clean up any resources
that may be waiting on message completion.

This is a rebase from version2, so please wait on the CI server before merging to be sure it builds.

[coveralls]

Coverage increased (+0.6%) to 36.76% when pulling a07e49a on swansontec:master into fe20c84 on libbitcoin:master.

[evoskuil]

Should this be backported to version2?

[swansontec]

We aren't using the "official" version2 because we have an incompatibility with the czmq library, so we've swapped that code out with a shim around vanilla zeromq. This change came from our local branch.

[evoskuil]

What's the czmq issue?

[evoskuil]

I would not be against eliminating the czmq/czmqpp dependencies if it can be done without creating a lot of additional code/complexity.

[swansontec]

The czmq library messes with signal handlers, which caused problems for us. Also, we use vanilla zeromq in other parts of our app, but we couldn't mix objects from the normal zeromq context with the czmq context. I don't know if the latest version of czmq has fixed any of this.

[evoskuil]

@swansontec We are planning to drop czmq and replace czmq++ with our own implementation in libbitcoin-protocol based directly on libzmq. Would this resolve your issue with czmq signal handlers?

[swansontec]

Yes, that would be perfect.

[evoskuil]

@swansontec BTW, did you ever try zsys_handler_set(NULL)? I just ran into the signal handler problem and this resolved it. It won't make a difference to my plans, just thought I'd mention it.

[swansontec]

No. I know they added a lot of stuff in the latest version, so this must have been one of the new additions.