Concurrent transactions

[frol]

Let's also ensure we test the API usability when app developers need to make concurrent transactions (function calls).

There are several challenges there:

• Nonce needs to be monotonically increasing, so if it is done naively, concurrent calls will get the same nonce for the transactions. The solution is to keep a local cache of nonce value, take inspiration from https://github.com/near/near-workspaces-rs/blob/445e86e4e73fc044962228c752fa4fc3493d24a7/workspaces/src/rpc/client.rs#L487-L523
• If transactions land to the nodes in such a way that early-nonce-transaction arrives later than the rest of the batch, and the batch makes it in the block, the delayed transaction will get rejected with INVALID_NONCE. See more context here and here. The solution is to use a pool of access keys or wait until it is resolved on the protocol level NEP-522: Optional Transaction Ordering near/NEPs#522

As part of this issue, I want us to doublecheck that it is possible to use near-api-rs in such situation and if not having a nice solution, at least have the option to have a helper wrapper with a pool of access keys.

[akorchyn]

The nonce caching and key pooling are implemented on the Signer level.

As long as the user keeps using the same Signer instance (that is wrapped into Arc). It should be fine.

The nonce issue could happen if the number of keys is less than the amount of TXs per sending period.
Also, there is a potential issue that several instances of the same key are running concurrently. They may mess with each other, but it's up to the developer to provide unique keys.

[akorchyn]

Example how to use it: https://github.com/akorchyn/near-api/blob/main/examples/account_key_pooling.rs