Make consistent use of "pool", "address type" and "receiver type",
in RPC documentaion, and deprecate bare uses of "type" in RPC APIs.
Fixes#5534
Co-authored-by: str4d <thestr4d@gmail.com>
This replaces the old implementation of asyncrpcoperation_sendmany
with one where all transaction construction is delegated to the
transaction builder. The capabilities of z_sendmany are somewhat
modified in the process:
* z_sendmany now permits sending funds from a Sprout address to
both transparent and Sapling addresses. PRIVACY NOTE: When
user sends a Sprout->Sapling transaction, the amount of the
transaction is publicly revealed.
* z_sendmany no longer supports transactions sending funds into
the Sprout pool, with the exception of change amounts when
sending from a Sprout address.
* When sending transparent coinbase funds to a set of shielded
addresses, the amount sent to recipients must fully consume
the input value and no change is permitted. This is a slightly
weaker constraint than was previously implemented; in the past,
only a single shielded recipient was allowed.
The p2p_nu_peer_management and rewind_index RPC tests still start from
Sprout, because they are explicitly (and only) testing network behaviour
across network upgrades.
The mempool_tx_input_limit test is removed because the flag has been
ignored since Sapling activation, and will be removed at some point in
the near future.
Kris Nuttycombe
Daira Hopwood
MarcoFalke
Alfredo Garcia
Jack Grigg
mdr0id
Eirik Ogilvie-Wigley
Simon