[tests] Remove rpc_zmq.py #14419

rpc_zmq.py is racy and fails intermittently. Remove that test file and move the getzmqnotifications RPC test into interface_zmq.py.

utACK 42a995a.

utACK 42a995ae4819ea472b211eb5088727a422fcbeb8

<!--e57a25ab6845829454e8d69fc972939a-->Reviewers, this pull request conflicts with the following ones:

• #14220 (Transaction relay privacy bugfix by sdaftuar)
• #14060 (ZMQ: add options to configure outbound message high water mark, aka SNDHWM by mruddy)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Why is the race not a bug that should be fixed?

Let's get rid of the racy test now and have it re-added as soon as a raciness has been fixed

I can't follow this logic.

As far as I can tell the operative test is added to the interfaces, so there would be nothing to restore.

Moving the test to another file seems reasonable (and faster!).

I'm not clear on why this test is racy.

@gmaxwell Sorry, my logic was incorrect :-) I incorrectly assumed that some racy subset of the test was being temporarily removed. I now understand that's not the case. A brainfart on my part :-)

I'm not clear on why this test is racy.

Here's a possibility, although can't demonstrate without the log files:

• bitcoind is started in rpc_zmq.py L30
• the rpc server starts in init.cpp L1232 (AppInitServers())
• there's then a race between: a) the test framework calling getzmqnotifications (rpc_zmq.py L31) b) the ZMQNotificationInterface being initialized in CZMQNotificationInterface::Create() (init.cpp L1339)

If (a) wins, then getzmqnotifications will return an empty object. See zmqrpc.cpp L36:

    if (g_zmq_notification_interface != nullptr) {
    ...
    }

Why is the race not a bug that should be fixed?

Not a bug. Just the test trying calling getzmqnotifications before the interface has been initialized.

Not a bug. Just the test trying calling getzmqnotifications before the interface has been initialized.

How is this not a bug. The call should block and wait until the interface has been initialized? Similarly on how we block the wallet on calls until it has caught up with the chainstate, this call should block until all notifications have been activated/deactivated immediately prior to this call.

How is this not a bug.

The help text for getzmqnotifications says "Returns information about the active ZeroMQ notifications." If you call the RPC before the interface is active, then it (correctly) returns an empty object since no notifications are active.

This is a little bit pedantic though. This is a tiny window condition which as far as I'm aware can only be hit in Travis which has weird scheduling and delays. I don't think this can cause any problems for end-users actually using the zmq interface.

I opened this PR to unblock #14336, which I think is a far more important goal than making sure that the zmq interface gets initialized before getzmqnotifications returns. If you want to fix that, by all means go ahead, but I don't think doing so should block #14336.