safeguard against same nonces in parallelized txs

[harrysolovay]

In some cases, two txs will trigger two system_accountNextIndex calls, which are parallelized, and produce the same nonce. This in turn invalidates one of the two txs. I believe we need some kind of nonce-management system––perhaps a dedicated Rune.

[harrysolovay]

Ideally we could somehow encode the parallelism restriction in the Rune type.

Rune.tuple([txA, txB])
//               ~~~
//               ^
//               Argument of type 'ExtrinsicRune<U, Chain>' is not assignable to parameter of type 'NonExtrinsicRune'.

• This would require some expensive typing + doing this in many rune factories + NonExtrinsicRune would exist solely for its signature, not as real type to be exposed to end devs...
• This is more trouble than it's worth
• A runtime error would likely suffice (runelint!)

On the flip side: if we could pull this off without too much overhead, it might be worth it.

EDIT

After reflection with @tjjfvi, it became clear this approach would...

• require too many Capi-specific changes to Rune (we'd prefer to keep the Rune system general)
• require communicating the chain-specific branding along with the tx (to avoid false positives of conflict)
• be unnecessary (eventually), as we'll want to implicitly batch

[harrysolovay]

I believe we should create a new error type DuplicateAccountNonceError which we could return and unhandle from SignedExtrinsicRune's sent in the case that someone fires off a new sent with a duplicate nonce.

Rune
  .tuple([sent1, sent2])
  .rehandle(DuplicateAccountNonceError, () => Rune.constant(...))
  .run()