rework hash calculation to not keep slot and write version

[jeffwashington]

Problem

It is constant time work to sort 400k storages by slot as opposed to n*lg(n)? [n=# accounts] work to sort account data by slot later.
Also, dragging around Slot and write_version per account can get expensive.

Summary of Changes

Take advantage of the fact that storages are sorted by slot to reduce the data we keep and eventually speed up hash and lamport calculation overall. Note that this isn't faster overall yet. So, this pr likely won't be actually submitted until the next phases and supporting pieces are ready. But, this is a logical unit of work. And, it isn't a serious regression and uses less memory, so there are some tradeoffs. With different bin tuning, this algorithm can be as fast or faster as-is.
We eliminate a write version and a slot for each account entry we find (keep in mind there are duplicates).

Fixes #

[jeffwashington]

total went from 6.0s (master) to 6.7s (this pr).
Things like changing bins will help us catch up and scale farther.
I also intend to rework how we do flatten and sort.

this change:
calculate_accounts_hash_without_index accounts_scan=1984282i eliminate_zeros=400528i hash=231545i sort=2685521i hash_total=61837974i flatten=1174477i storage_sort_us=20538i unreduced_entries=62270664i collect_snapshots_us=214111i num_snapshot_storage=372887i total=6711002i
calculate_accounts_hash_without_index accounts_scan=2209913i eliminate_zeros=443076i hash=233774i sort=1473023i hash_total=61837974i flatten=1490250i storage_sort_us=20576i unreduced_entries=62270664i collect_snapshots_us=228110i num_snapshot_storage=372887i total=6098722i
master^

[codecov]

Codecov Report

Merging #17685 (c0da989) into master (708bbcb) will increase coverage by 0.0%.
The diff coverage is 81.6%.

@@           Coverage Diff            @@
##           master   #17685    +/-   ##
========================================
  Coverage    82.7%    82.8%            
========================================
  Files         431      433     +2     
  Lines      120590   120773   +183     
========================================
+ Hits        99839   100031   +192     
+ Misses      20751    20742     -9     

[jeffwashington]

The main change here is that we need to find the last entry for each pubkey. The previous code wanted the first item. Since we read directly from appendvecs and write_versions increase as we read, this is the natural sort order.

[jeffwashington]

this messy code is required if we have > 1 append vec per slot. We need to write_version to be in increasing order in the final accumulated results.

[jeffwashington]

Building off this pr, the next step gets us from 6s (master) to 3.6s by reworking flatten and sort.

[sakridge]

looks good

Pull request has been modified.

[jeffwashington]

it turns out there is no discernible penalty for using the multiple storages/slot code path all the time, so that makes things simpler.
Also, there is enough noise in the measurements that it is approximately the same speed for this version of hash calculation vs keeping slot and write version. Perhaps it because the # of bins have increased in master.