Try verifying signatures against the last consensus branch ID on failure

[str4d]

Currently, if a transaction is received that is signed with a different consensus branch ID, the error returned is either a plain signature failure (if fully-shielded), or more commonly a rather inscrutable failure in the scripting system (for transparent signatures). If we encounter this error, we could try re-verifying with the previous epoch's consensus branch ID. If that succeeds, then we can return a more helpful error to the sending node / user. The downside to this is that it would double signature verification load for failure cases (both normal and adversarial), but if we localise it to just the signature verification itself (i.e. for transparent signatures, trying both inside the script stack) then we aren't fully-doubling the load (as we don't need to re-evaluate the script).

[tromer]

Example of a user encountering the cryptic error:
https://discordapp.com/channels/669694001464737815/671029188353851393/679969630156357662

[rex4539]

Another example: #4345

[rex4539]

One more: https://forum.zcashcommunity.com/t/zec-transactions-not-sending-from-ledger-nano-s

[str4d]

#4371 implements this for transparent and JoinSplit signatures. Sapling signatures are checked inside the Rust codebase along with the proofs, and so we need a larger refactor before we can efficiently implement the same test.

[rex4539]

One more: #4392

[str4d]

v5 transactions commit directly to the consensus branch ID, so this is not an issue for them. The only remaining area is Sapling signatures on v4 transactions as described above.