Ordered account insertion into merkle trie (I)

[tsachiherman]

Summary

Inserting ordered hashes into the merkle trie improve its insertion speed dramatically. The goal of this change is to modify the insertion that doing so that these would always be in-order.

We currently have two such use cases :

• Rebuilding a local merkle trie from the accounts themselves
• Node catching up using the fast catchup. This would be handled on the server side by ordering the accounts on the catchpoint file.

This PR addresses the first part, using an ordered accounts hashes to be inserted into the trie.
The new orderedAccountsIter is intended to replace the encodedAccountsBatchIter, but that would only be possible on the subsequent PR.

Performance Plan

I added a benchmark to test the gains:

Number of accounts	Before the change	With the change	Performance gains
6,000,000	293 seconds	80 seconds	266%

The 6M accounts were chosen since it's roughly the number of accounts we currently have on mainnet.

Test Plan

Existing tests already cover the functional portion of this PR.

[ghost]

Added some minor comments. Question: how efficient is using sql's orderby / indexing as a sorting algorithm?

[tsachiherman]

Added some minor comments. Question: how efficient is using sql's orderby / indexing as a sorting algorithm?

I'm not sure that we have a good alternative. We don't have enough memory to load it all in anyway.

[ghost]

Updated changes look good

[algonautshant]

Looks good.
I feel like this can be simplified. So I need to understand why all these cases are needed.

[algonautshant]

Why this step needs to return? Can't it directly call Next to advance to oaiStepSelectFromOrderedTable?

[algonautshant]

Looks great.
Thanks for the changes.
Just one comment about closing the iterator.

[algorandskiy]

LGTM, not sure although why do we need such level of granularity/steps within the Next() function