multi: Make JSON-RPC rescan docs match reality.

[davecgh]

The semantics for discovering transactions that involve specific addresses and outpoints that a client is interested in changed some time ago to be based on loading transaction filters.

It appears that the JSON-RPC API documentation was not updated to match the new reality at that time, so this updates the documentation accordingly.

In particular, it updates the JSON-RPC API documentation for the loadtxfilter, notifynewtransactions, and rescan methods as well as the blockconnected and blockdisconnected notifications to match the correct parameters and semantics.

Next, since rescan now blocks until it finishes and therefore no longer is involved with or sends notifications, this removes references to rescan from all notifications and removes the longer available rescanprogress and rescanfinished notifications.

Finally, it adds documentation for the releveanttxaccepted notification sent in response to a transaction that matches the loaded transaction filter being added to the mempool.

[matheusd]

LGTM.

Orthogonal to this PR, but I feel we don't really need rescan in dcrd anymore, now that we have CFilters (we can't drop it yet though, because dcrw still uses it in rpc mode).

[davecgh]

LGTM.

Orthogonal to this PR, but I feel we don't really need rescan in dcrd anymore, now that we have CFilters (we can't drop it yet though, because dcrw still uses it in rpc mode).

Perhaps. I will note that recsan is more efficient than using cfilters though because cfilters don't tell you which transaction matched, only than one of them in the block matched w.h.p. You then need to acquire the entire block from somewhere and loop all of the inputs and outputs of all of the transactions in that block to find which ones are relevant. Rescan, on the other hand, essentially directly does the latter server side and gives the actual serialized transactions that match.

[matheusd]

Perhaps. I will note that recsan is more efficient than using cfilters though because cfilters don't tell you which transaction matched, only than one of them in the block matched w.h.p. Rescan, on the other hand, gives the actual serialized transactions that match.

We'd have to measure to figure out the performance points of when it makes sense to use cfilters vs rescan, in terms of size of the txFilter, expected frequency of match, average size of blocks, etc.

[davecgh]

I haven't measured it, but I can tell you from actual usage experience that wallets that are super busy (and hence have matches in almost every block) become extremely slow over SPV while they remain quite snappy with rescan+RPC.