Update fee calculation and thresholds so that large z_sendmany transactions are mined

[bitcartel]

Background: This ticket is based on real-world usage where a user failed to send funds to 1,500 taddr recipients.

A single joinsplit transaction from zaddr -> 1384 taddr recipients will be propagated between nodes, and eventually mined as a low-fee transaction, given that the fixed z_sendmany fee of 10,000 still applies.

However, a transaction from zaddr-> 1385 taddr recipients will not be mined as mempools will reject the transaction for having a fee which is too low.

Firstly, the transaction has a size of 49001 bytes, one byte more than the threshold of DEFAULT_BLOCK_PRIORITY_SIZE - 1000 (where DEFAULT_BLOCK_PRIORITY_SIZE is 50000). Breaking this size threshold means that a minimum fee of 0 is no longer applicable for this transaction.

Second, the minimum fee which is now applicable is calculated from the formula nSatoshisPerK*nSize / 1000 where the default value for nSatoshisPerK comes from minRelayTxFee which is 5000. Thus, with nSize = 49001, the minimum fee is 245,005 i.e. > 24x the actual fee of 10,000.

When resolving this issue, we must bear in mind that multiple notes may be consumed across multiple joinsplits in order to add value back to the transparent pool.

Related: #1719 (dust and fees)
Related: #1808 (based on max tx size, limit on taddr recipients is ~2900)

[nathan-at-least]

Immediate step: notify users a work-around is to split large z_sendmany calls (with >= 1385 t-addr recipients) into multiple calls, each with <= 1384 recipients.

Those numbers will be different with more or fewer JoinSplits.

Longer term: what would it take to update the existing wallet fee estimation for 0 JS transactions to properly account for >0 JS transactions, so that there's no special case for >0 JS?