Make transaction issue more predictable.

[JoelKatz]

Currently, if a transaction fails to process for some reason, such as "no network" errors, the transaction issuer can be in jam. For example, if transaction 8 is in limbo when 9 fails, issuing a new transaction 8 can make the old transaction 9 valid again. This leads to unpredictable and difficult to handle cases.

Two issues need to be decided:

1. If a transaction is locally submitted and it fails authoritatively, should the transaction be held or dropped? Dropping the transaction allows the transaction issuer to rely on the transaction never being processed. Holding the transaction increases the changes it will be processed.

2. Do we want to add an optional "prior transaction hash" field to a transaction. That way, if you issue transactions 8, 9, and 10 and then something happens, if you issue a new transaction 8, transactions 9 and 10 are forever invalidated (if they used this option) because the original transaction 8 can never be applied.

Regardless of these decisions, we need to make transaction retry a bit more predictable. If we do decide to retry a transaction, we should at least have a defined minimum hold time.

[ahbritto]

What would be the type of new field?

Who is the minimum hold time for? Should this be recommended hold time? I suspect we only want this to really apply to transactions submitted locally? Also, how does rebroadcast occur?

[JoelKatz]

The new field would just be the 256-bit hash field "PreviousTxnID" that we already have. If present, this field would be compared to the corresponding field in the account root node when we check the sequence number. If they don't match, we'd return an inappropriate prior transaction error, which we also already have.

The minimum hold time would provide some predictability in getting locally submitted transactions out. The rebroadcast would occur when a new last closed ledger results from the consensus process. All held transactions would be test applied. If it authoritatively fails, it would be discarded. If it applies, it would then be rebroadcast just in case and added to our next proposal. It might not get in the next round (because the rebroadcast might be too late) but it should get in the one after that.

[JoelKatz]

The master branch will now allow transactions that include a "PreviousTxnID" field. The "secure_chaining" branch that adds full support for this has been merged into the "develop" branch. The hold logic has not been worked on yet.