[1.2.1] TraceAPI: Fix for finding trx after starting from snapshot

[heifner]

When starting from a snapshot, not all stride files are present. Instead of attempting to find the first stride file and failing, loop through the trx id files on disk. Also now searches in reverse order assuming the trx searched for is more likely to be in a recent block.

Resolves #1693

[greg7mdp]

Is that new solution slower than using the stride files when present? Should we try the stride files first, and in case of failure use this new implementation?

[heifner]

Is that new solution slower than using the stride files when present? Should we try the stride files first, and in case of failure use this new implementation?

Both approaches use the stride files. The old approach started at stride 0 and worked its way up to the last stride. If the trx is in the last stride it has to search all previous before finding it in the last stride. The new approach assumes the searched for trx is more likely to be in the most recent stride(s); so it searches in reverse from the latest stride back to the oldest.