Change how transaction status polling is done

Currently we send transactions in near-api-js using broadcast_tx_commit and it caused issues like https://github.com/near/near-api-js/issues/127 because nearcore will return an unstructured error for timeout and it makes it difficult to handle on the client side. However, not only does the error on nearcore side take longer time to fix, broadcast_tx_commit is also not really the best way to submit transactions. I suggest that we use a combination of EXPERIMENTAL_broadcast_tx_sync and EXPERIMENTAL_check_tx to handle transaction submission and status checking on near-api-js side. This completely eliminates the possibility of timeout error from nearcore side and allows more flexibility for polling transaction status as there is no internal polling in nearcore in either EXPERIMENTAL_broadcast_tx_sync or EXPERIMENTAL_check_tx.

Some caveats:

• Errors need to be handled properly. When EXPERIMENTAL_check_tx returns InvalidNonce for example, it actually means that the transaction likely has already succeeded and therefore the nonce on the access key has increased, making the original transaction invalid.
• When EXPERIMENTAL_check_tx returns None, it means that the transaction is still valid, but this might imply that something went wrong in between (get stuck in mempool for example). So near-api-js should have some timeout on its own to decide that the transaction is not accepted and a new one should be sent.

@vgrichina @kcole16 What do you think?

[bowenwang1996]

@vgrichina it is available on betanet and will be released to testnet next Monday. Given that it is already Thursday I won’t think it makes sense for me to patch testnet with this commit right now.

[frol]

It appears that something doesn’t work very well. I have seen people reporting nonce issues and other issues with retry. We should probably look into it.

Seems to be resolved in https://github.com/nearprotocol/nearcore/pull/3061