Possible transaction status events.

This events are being emitted by TransactionPool watchers, which are also exposed over RPC.

The status events can be grouped based on their kinds as:

1. Entering/Moving within the pool: - Future - Ready
2. Inside Ready queue: - Broadcast
3. Leaving the pool: - InBlock - Invalid - Usurped - Dropped 4. Re-entering the pool: - Retracted 5. Block finalized: - Finalized - FinalityTimeout

The events will always be received in the order described above, however there might be cases where transactions alternate between Future and Ready pool, and are Broadcast in the meantime.

There is also only single event causing the transaction to leave the pool. I.e. only one of the listed ones should be triggered.

Note that there are conditions that may cause transactions to reappear in the pool.

1. Due to possible forks, the transaction that ends up being in included in one block, may later re-enter the pool or be marked as invalid.
2. Transaction Dropped at one point, may later re-enter the pool if some other transactions are removed.
3. Invalid transaction may become valid at some point in the future. (Note that runtimes are encouraged to use UnknownValidity to inform the pool about such case).
4. Retracted transactions might be included in some next block.

The stream is considered finished only when either Finalized or FinalityTimeout event is triggered. You are however free to unsubscribe from notifications at any point. The first one will be emitted when the block, in which transaction was included gets finalized. The FinalityTimeout event will be emitted when the block did not reach finality within 512 blocks. This either indicates that finality is not available for your chain, or that finality gadget is lagging behind. If you choose to wait for finality longer, you can re-subscribe for a particular transaction hash manually again.