Zcash: Full-round-trip-confirmation transaction submission RPC interface

[nathan-at-least]

If there were an RPC interface which only considers an 'operation' successful once all of the transactions involved have 10 confirmations, this would codify our recommended practice.

Beyond providing all of what the user wants in the success case, this has excellent value for detailed feedback to users. Right now different kinds of failures which are tangles of confusing complexity, such as cases where:

• a transaction is confirmed, then disappears in a reorg,
• a transaction is created, but no neighbors accept relay of the transaction,
• a transaction is created and relayed, but is not mined 'soon enough' (note that #754 would make 'soon enough' explicitly well defined),
• creating a transaction failed,
• -and possibly other conditions we're not thinking of.

Note that case 2 has several important subcases I'm aware of:

• the transaction is rate-limited by neighbors,
• the transaction violates some AcceptToMempool policy of neighbors (this can be especially confusing if all the neighbors have a new policy the user doesn't know about, such as #2343).

[tromer]

Related to #1952. This one is about when the operation is considered "successful", whereas #1952 is about zcash-cli waiting for an operation to succeed/fail.

[tromer]

About detailed feedback: duplicate of #1959?

[nathan-at-least]

I consider this a particular approach to #1959, whereas there may be improvements that meet #1959 requirements without any changes to our existing RPC interface (such as improved logging or alerting).

Since this ticket advocates a new RPC interface, it will only benefit users who upgrade their application logic / integration code, whereas improved logging could be helpful for them in a backwards compatible manner.

[tromer]

Somewhat related to https://github.com/zcash/zcash/issues/1962#issuecomment-361385227, which is about a z_sendmany variant that, in case the funds are owned-but-unavailable (e.g., change from a not-yet-mined local z->*), waits for them to become available (i.e., for the transaction that generated the change to be mined) instead of failing.