rpc-v2/tx: Implement transaction_unstable_broadcast and transaction_unstable_stop

[lexnv]

This PR implements the transaction_unstable_broadcast and transaction_unstable_stop.

The transaction_unstable_broadcast submits the provided transaction at the best block of the chain.
If the transaction is dropped or declared invalid, the API tries to resubmit the transaction at the next available best block.

Broadcasting

The broadcasting operation continues until either:

• the user called transaction_unstable_stop with the operation ID that identifies the broadcasting operation
• the transaction state is one of the following:
  • Finalized: the transaction is part of the chain
  • FinalizedTimeout: we have waited for 256 finalized blocks and timedout
  • Usurped the transaction has been replaced in the tx pool

The broadcasting retires to submit the transaction when the transaction state is:

• Invalid: the transaction might become valid at a later time
• Dropped: the transaction pool's capacity is full at the moment, but might clear when other transactions are finalized/dropped

Stopping

The transaction_unstable_broadcast spawns an abortable future and tracks the abort handler.
When the transaction_unstable_stop is called with a valid operation ID; the abort handler of the corresponding transaction_unstable_broadcast future is called. This behavior ensures the broadcast future is finishes on the next polling.
When the transaction_unstable_stop is called with an invalid operation ID, an invalid jsonrpc specific error object is returned.

Testing

This PR adds the testing harness of the transaction API and validates two basic scenarios:

• transaction enters and exits the transaction pool
• transaction stop returns appropriate values when called with valid and invalid operation IDs

Closes: #3039

Note that the API should be enabled after: #3084.

cc @paritytech/subxt-team

[lexnv]

We are effectively trying to resubmit the transaction to the next best block here; if we cannot make progress at this time:

• submit_and_watch directly returned a recoverable error (ImmediatelyDroped etc)
• submit_and_watch produced an event that may be recoverable (Invalid / Dropped etc)

When we get the Invalid event, the transaction-pool will ban it for some time (default 30 mins). In this case, the looping seems redundant unless chain developers manually pick another timeout.

However, I believe we can simplify this and try to submit the transaction only once.
From the transaction_unstable_broadcast, the phrasing states that the server tries to broadcast, but without any guarantees:

JSON-RPC server will try to propagate this transaction

This could be interpreted as we'll submit the transaction to the transaction pool now, and if it fails or is invalid we'll stop.

@skunert would love to get your thoughts on this 🙏

[skunert]

Yeah sounds like its not enforced by the spec, but IMO the current implementation makes sense. If we can recover and retry in the next block, why not.

[skunert]

Hmm could someone abuse broadcast_ids by calling broadcast for invalid tx over and over, but never calling stop_broadcast? The future would terminate but the broadcast ids map would grow and never get cleaned up.

[lexnv]

Good catch! I've removed the operationId from our internal mappings as soon as the broadcast future exits.

I believe this is in-line with the spec; since the tx_stop mentions it works for active broadcasts:

A JSON-RPC error is generated if the operationId doesn't correspond to any active transaction_unstable_broadcast operation.

As a side-effect have added a small task executor wrapper for our testing; just to make sure we don't race between tx_stop and broadcast future clearing the internal state

[skunert]

Yeah sounds like its not enforced by the spec, but IMO the current implementation makes sense. If we can recover and retry in the next block, why not.

[skunert]

Looks nice!