feat: fast execute

[PhilippeR26]

Motivation and Resolution

In some cases, it's important to be able to process as fast as possible consecutive transactions. Gaming is fond of this feature.
A normal transaction (with myProvider.waitForTransaction(txH)) needs more than 10 seconds. To be able to process a transaction each 2-3 seconds, use:

const myProvider = new RpcProvider({
  nodeUrl: url,
  specVersion: '0.9.0',
  blockIdentifier: BlockTag.PRE_CONFIRMED,
});
const myAccount = new Account({
  provider: myProvider,
  address: accountAddress0,
  signer: privateKey0,
});
const call1 = gameContract.populate('decrease_qty_weapons', { qty: 5 });
const tipStats = await myProvider.getEstimateTip();
const resp = await myAccount.fastExecute(
  call1,
  { tip: tipStats.recommendedTip },
  { retries: 30, retryInterval: 500 }
);
if (resp.isReady) {
  const call2 = gameContract.populate('increase_qty_weapons', { qty: 10 });
  const resp = await myAccount.fastExecute(
    call2,
    { tip: tipStats.recommendedTip },
    { retries: 30, retryInterval: 500 }
  );
}

Do not need usage of provider.waitForTransaction()
Fastest encountered transactions was 1.8s between 2 transactions.

• This method requires the provider to be initialized with pre_confirmed blockIdentifier option.
• Rpc 0.9 minimum.
• In a normal myAccount.execute() call, followed by myProvider.waitForTransaction(), you have an immediate access to the events and to the transaction report. Here, we are processing consecutive transactions faster ; then events & transaction reports are not available immediately.
• As a consequence of the previous point, do not use contract/account deployment with this method. Use the normal way.
• fastExecute() is generating a significant amount of communication with the node. To use sparingly, especially with a public node.

Usage related changes

New feature. See above.
Responses:

• true: ready for new tx.
• false: timeout.
• Error: error in Starknet or when communicating with node.

Development related changes

• Account.fastExecute() is using Account.execute(), then a new RpcProvider.fastWaitForTransaction()
• default retries & retryInterval have been defined after large test campaign.
• We are waiting to be a least PRE_CONFIRMED, then we are waiting that nonce bump (can occur before or after pre_confirmed status).
• Tested in Devnet0.5.0, local Pathfinder v0.18.0, local Juno v0.15.1, public Pathfinder Blast, private Equilibrium pathfinder node, Spaceshard Juno, ...
• test suite executed in devnet, local Pathfinder& local Juno.

Checklist:

• Performed a self-review of the code
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[tabaktoni]

Interesting, but gaming should use ws connection.

[PhilippeR26]

Interesting, but gaming should use ws connection.

I think we could have both rpc & ws.
I made the job for rpc ; but for ws, we have not yet a ws0.9 that can subscribe to PRE_CONFIRMED status.

[tabaktoni]

Still think that gaming should use ws, I don't see why we should not have additional experimental fast flow.
lgtm