minifront should implement a transaction queue, instead of simultaneously building transactions

[turbocrime]

Is your feature request related to a problem? Please describe.

nullifiers may only be used once.

in local state, consumption of nullifiers is handled by the block processor, when a transaction appears in a compact block.

but users may plan and build more than one transaction at a time.

when the first transaction using these inputs is broadcast to the chain, the nullifiers it consumes become unavailable to subsequent transactions. any simultaneous plan-witness-build-broadcast has no way to notice that its inputs have become invalid.

so it is likely that a user attempting to rapidly conduct several transactions (as when claiming auctions) will see the first succeed, and then the rest rejected by the fullnode with an unfriendly error about nullifiers.

this failure doesn't destroy anything. the user can immediately re-attempt new transactions of the same effect and observe success.

but it is annoying, and it means that a user must understand this failure, and manually initiate each transaction in sequence as the prior transaction completes, instead of simply performing UI actions.

Describe the solution you'd like
Minifront should not begin building a transaction until any present plan-witness-build-broadcast sequence is resolved. This could be implemented as a global transaction fifo.

Describe alternatives you've considered
Alternatively, ibc could add a 'nullifiers pending use' table that is checked during plan-witness-build-broadcast. This is more complex from a state perspective, but would be a better solution overall. Benefits:

• services could simultaneously build in parallel without fear of collision, accelerating perceived speed
• block processor could take advantage of this table to accelerate nullifier searches when scanning incoming blocks
• third-party consumers of services and block-processor would also gain this feature

Additional context
This is very relevant as long as GDA sub-auctions each require an independent close/withdraw transaction, of which there may be very many.