doc/zmq.md describes each topic and the per-topic sequence numbers, but says
nothing about when notifications are delivered relative to the node's own
state. This trips up clients that treat a notification as a snapshot: ZMQ
messages are queued on the SerialTaskRunner (src/scheduler.h) that backs
ValidationSignals and dispatched from the scheduler thread after the block
or mempool change is already applied, so a subscriber that reacts to
hashblock by calling getbestblockhash can legitimately get a later block
than the one it was just told about.
This adds a paragraph to the Remarks section stating that:
- notifications are dispatched asynchronously, after the state change,
- a notification should be used as a trigger to re-query rather than as a snapshot of current state,
- ordering is preserved within a topic, but not across the ZMQ,
-*notifyand RPC interfaces, which run independently (-blocknotify, for instance, runs its command on a detached thread insrc/init.cpp).
Documentation only; no behaviour change.
This addresses part of #14278.
