Surface error messages returned by Resource Provider APIs to user

[aaroncox]

During the Resource Provider sampling process, we can catch errors involving the transaction before its sent to the users wallet. These aren't resource errors, they are errors with the contract the user is trying to interact with. Currently these errors are returned as part of the API response but not surfaced to the user. The current flow is:

• User starts transaction.
• Transport checks resource requirements.
• If there's an error during sampling, the API returns the error to the transport.
• The transport currently just proceeds without cosigning and without prompting the error.
• The user signs using their wallet, and it often fails from resource issues.
• The user powerup/rents/etc and tries again, and now they see the error.

We should change the transport to surface the errors that occur during sampling. The flow should be:

• User starts transaction.
• Transport checks resource requirements.
• If there's an error during sampling, the API returns the error to the transport.
• The transport prompts the error to the user and the transaction flow is halted.
• The user corrects the error (if possible) and resubmits, the transaction is cosigned and successful.

[jnordberg]

I'm worried about false positives here, with the flow you proposed the user would be prevented from transacting if the resource provider stops a transaction that would actually go through if submitted normally.

I think a better approach would be for the transport to store the error from the resource provider and if the transaction is submitted and gets a resource error we surface the stored error instead.