Improve "immediate / local transaction failure mode" reporting

[nathan-at-least]

We want to improve error reporting comprehensively, as in #1959. One change to the RPC interface that could help with that is #2345.

There is an important subset of #1959 which are failures that can be detected quickly by the local node, without interaction with other nodes. Whenever possible these errors should explain the problem and how a user might work around it.

Fixing this segfault is important because the bug may be "deep".

However, there is a "higher" UX / interface bug here: Requesting a transfer from a z-addr's note which has 0 block confirmations is never valid. Users don't explicitly refer to notes, and therefore cannot make such a request (explicitly). So, how can we fix the UX problem (which is logically distinct from the segfault)?

Given that MINCONF is a minimum, one option is to clip the minimum to 1 effectively whenever the sending address is a z-addr. I kind of dislike this, because it's different behavior than for t-addr send addresses.

Here are some brainstormed error messages related to note selection or transaction size, which explain both the cause and the work around:

• "This request requires spending notes which are not yet confirmed. Wait until outstanding transfers are confirmed in 1 or more blocks, then retry this request."
• "This request can only be satisfied by using $INCOUNT input notes, but the default policy rejects transactions with more than $K inputs. Make multiple smaller transfers. Suggestion: requesting a transfer of ≤ $X ZEC will select fewer than $K inputs and will address this issue." - note this is due to Add ability for node to reject tx from mempool by number of tx inputs #2342 hack, and depends on miners and nodes not changing the default. If the network de facto default changes this error message will become misleading and make things worse!
• "This request would require a $SIZE byte transaction, but consensus rules limit transactions to 100,000 bytes. Make multiple smaller transfers. Suggestion: requesting a transfer of ≤ $X ZEC will result in a transaction less than the 100,000 byte cap."

Note that the suggestion sections assume that note selection is deterministic for a given set of user request parameters and that note composition won't change between requests. The second bullet also assumes the network default configuration. When these assumptions fail, the error messages can become worse. (This is one important drawback of per-node configurable or tunable parameters.)

[nathan-at-least]

#1970 falls within this ticket. Ideally invalid requests can be detected quickly. The current behavior (which #1970 attempts to address) is that detection does not happen until after proof generation. Still, even pre-#1970 this is still a "local" error message and can include a useful work-around suggestion.

[tromer]

The first case ("request requires spending notes which are not yet confirmed") is related to to #1962.

[nuttycom]

Closing as obsolete; this kind of issue has been resolved via the unification of shielded spend functionality.