use sequence zmq event instead of hashblock

[RuslanProgrammer]

Fixes: #198

We should use a better zmq event for our use case.

Let's compare the delivery times of the hashblock and sequence events.

- SEQUENCE (103) -
87984c9bc7b6070e9f9b2fe8472de8799e1851b4a0b25a5f5e5287ae70adaa11 C None
4.592926979064941
- HASH BLOCK (101) -
87984c9bc7b6070e9f9b2fe8472de8799e1851b4a0b25a5f5e5287ae70adaa11
4.592989921569824
- SEQUENCE (104) -
ea49e0bc38f32651a6f04485fae70a364a4c2724baf43f3e5d282431e95f45c9 A 3
4.8370912075042725

The difference between hashblock (which we are using right now) and sequence for "Transactionhash added mempool" is more than 0.2s (for my host PC). This means there is a significant delay between these two events. Based on the code, we use a zmq notification to trigger the update() and check the node's mempool for new transactions. However, due to the significant delay, the hashblock subscription does not work properly.

This PR is open to choosing another subscription type and filtering the specific sequence event.

[Randy808]

The zmq_event_receive is currently only consumed by the Waiter, signal, and is really only used in the wait method when the accept_block_notification is true. This only happens when wait is invoked in the main loop in electrs.rs which controls mempool updates like you noted in your description.

One issue I see with this approach is the overhead from the increased number of Mempool::update calls. The hashblock notification isn't being used as a way to detect if a transaction hash was added to the mempool, it's a way to communicate to the main loop that we need to remove confirmed txs from the mempool. Whenever it's called, we get all the txids from the node's mempool, remove the txids in our mempool that are no longer present, and make additional calls to retrieve the transactions we don't have. To avoid updates from being invoked for every tx, I'd suggest filtering for just block events.