tx - txnNotFound Error should include which ledger versions it searched

[intelliot]

(Copied from RIPD-1705)

With online deletion, there is a race condition where a client could incorrectly conclude that a transaction is not in a validated ledger because that ledger was deleted after the client queried which ledgers were available on the server.

This is an edge case in reliable transaction submission: you have to know that a transaction is not in a range of validated ledgers before you conclude that it has failed. The scenario in question goes something like this (where "you" are a rippled client):

• You submit a transaction T.
• Transaction T becomes validated in ledger M, but you don't know that yet.
• You see that the server has ledger M in its list of available ledgers, either because you're subscribed to the server's ledgerClosed stream, or by checking server_info.
• After you've asked about the available ledgers but before you query for the transaction, the server deletes ledger M. (If you're following the ledgerClosed stream, this would have to be after a number of ledger versions have closed equal to or greater than online_delete, which is minimum ~15 minutes. If you asked via server_info, this could happen immediately if the ledger was in the range to be deleted when online_delete next ran.)
• You ask the server about transaction T and get a txnNotFound response from the server.
• You incorrectly conclude that the transaction T is not in ledger M, because you thought that the server had ledger M.

Even if you check server_info again after not finding the transaction, there's a small chance that the ledger in question was just finished downloading in between. Naturally, most of this stuff is unlikely, but becomes more plausible if there's an unusual amount of network latency between client and server.

One very straightforward and robust fix for this problem would be for the txnNotFound response to include a list of ledger indexes it checked. Essentially, paste the complete_ledgers field of server_info—all the validated ledger versions the server checked—into the error message. (It could also be in the form of ledger_index_min / ledger_index_max fields as the account_tx command returns.) That way, the client knows without risk of race conditions exactly which ledgers the transaction is not in.

[intelliot]

#3145 -- included in 1.5.0-b1