Remove z_sendmany restriction on duplicate addresses

[leto]

This is from https://github.com/zcash/zcash/issues/2955

and will potentially allow HushList protocol to send up to 512*54 = 27KB of memo data to a single address without requiring a multipart protocol. This is possible because all memos will share the same txid and can be uniquely identified and ordered by their transaction output index.

[leto]

This upstream Zcash PR is related, as I think we may need it to reconstruct these kind of memos on the receiver-side, otherwise we don't know the correct order. Alternately, we embed the order in the memo, less ideally: https://github.com/zcash/zcash/issues/2932

[leto]

There should be an inherited Zcash test for this behavior, or we should write a new one as this an important change inside z_sendmany

[leto]

First "supersized" HushList memo transaction is here: https://explorer.myhush.org/tx/35b728b81335a2ecf218c338ae11941a6bdff43b4070a69b1df87e78968e5f74

One taddr send to a duplicated zaddr five times, effectively sending a 5.5KB memo field in one transaction. In theory the max recepients of 54 zaddrs will allow a 27KB memo to one person, or three 9KB memos to three people in one transaction, and other possibilities.

[leto]

Here is a "mega-sized" 49KB Hush transaction

https://explorer.myhush.org/tx/b2375b5ebbefffad6c0cdda7a2b1ee9ac2e0f206e37ebd2186c426bd65c024b7

54 outputs, all the same zaddr, encoding a 27KB PNG file, took 40 minutes to execute.

[leto]

More details about the mega xtn here: https://gist.github.com/leto/b0c3c7d668eea2fdc5f365671ae3fa0b

It seems that z_sendmany/z_listreceivedbyaddress do not preserve the order of outputs in a transaction, so the receiver needs to receive additional metadata to re-assemble the data

[FireMartZ]

Looks good to me.