[FEAT] use ZMQ pub / sub for block processing trigger

[MorningLightMountain713]

Currently initiateBlockProcessor is polling fluxd every 5 seconds for blocks. This is a lot of wasted effort, and in some cases, there can be a 5 second delay getting the latest block info.

If we were to use the fluxd zmq facility, could then subscribe, to the hashblock topic:

davew@crab:~/zmqtest$ node test_zmq.js
Subscriber connected to port 28332
hashblock: 00000007d31f8f652a06df507661297dd0d43b5cf36af3f44f3db3153d23680b, sequence: 156
hashblock: 00000001f87986e88fcfdca9a7483a1fd71053a25669de951c2ccaa875c71a13, sequence: 157
hashblock: 0000000806455c7db47bf708e43c666e8e322ef28be37232dce8466a3f8b0258, sequence: 158
hashblock: 0000000402f24de0e026b3da40b2e331c0698c0c549ff25bc07ba04ceb842059, sequence: 159
hashblock: 00000000e96f312cc25b4a5f7971f2f88f3c0076f948d5e6df74ed296bb5c4e5, sequence: 160
hashblock: 00000007ff30f92a6d07505bf238f272887466434fd93449a6a6f37f098df812, sequence: 161

This is trivial to setup, fluxd is only one line and fluxOS is only a few lines, and requires the zeromq npm package.

fluxd setup:

zmqpubhashblock=tcp://127.0.0.1:28332

Could get the blocks this way too, but I propose just using it for a trigger so that we know there is a block waiting using the existing mechanisms.

There is no authentication on this endpoint. However, that isn't a problem. The authentication on the RPC endpoint isn't for the client, it's to protect the rpc endpoint in case the operator mistakenly opens this up to the internet. The zmq endpoint is read only also, and can be run on the same port as the rpc server. (obviously on localhost)

Unless there are any objections, I'll incorporate this into my existing rework of the block processor etc. I'll implement a fallback mechanism in case zmq endpoint isn't available, as well as a fallback to poll the blockheight if a block isn't received on the topic within x minutes (probably like 10 or something) as a safety precaution.