What should ATxM do for a tx that causes MalformedException (during broadcast phase) and therefore can cause other txs in queue to be starved until dealt with

[derekpierre]

Related to @manumonti 's comment here - nucypher/nucypher#3489 (comment).

Should we consider this strategy [remove and requeue tx] as the default one for ATxM?

If I understand correctly, when broadcast_failure because of unrecoverable_error 
(malformed tx, for instance), the TX is kept in the queue unless you explicitly remove it, 
which doesn't seem to make sense much sense.

WDYT?

and my response - nucypher/nucypher#3489 (comment)

That's a really good observation/question. 

It's possible but the tough part is that ATxM (as a standalone library and not specific to `nucypher`) 
maintains a FIFO queue, which could contain queued transactions that are dependent on transactions
in the queue ahead of it being executed first. So proactively removing and requeueing a transaction can 
throw the order out of whack. It's one of the reasons the failure callables (`on_fault`, `on_broadcast_failure` etc.) 
are mandatory (https://github.com/nucypher/ATxM/pull/31). That way instead of ATxM guessing what to do, 
the user with more context/insight into the transactions to execute can proactively do something about it.

In `nucypher`'s case, the added ritual phase transactions are independent and self-contained, 
so re-ordering them is fine, but perhaps for other use cases, it isn't that clear-cut/easy.