ledger: create catchpoint tracker

[tsachiherman]

Summary

Extract catchpoint logic out of the accounts update tracker.

Test Plan

Refactor existing unit tests.

[codecov-commenter]

Codecov Report

Merging #3085 (848dd28) into master (9b39c66) will decrease coverage by 0.15%.
The diff coverage is 52.87%.

@@            Coverage Diff             @@
##           master    #3085      +/-   ##
==========================================
- Coverage   47.34%   47.18%   -0.16%     
==========================================
  Files         364      365       +1     
  Lines       58296    58361      +65     
==========================================
- Hits        27599    27537      -62     
- Misses      27515    27631     +116     
- Partials     3182     3193      +11     

Impacted Files	Coverage Δ
data/pools/transactionPool.go	43.20% <0.00%> (-0.33%)	⬇️
ledger/voters.go	52.30% <0.00%> (ø)
ledger/catchpointtracker.go	41.54% <41.54%> (ø)
ledger/acctupdates.go	64.82% <71.42%> (+0.47%)	⬆️
ledger/tracker.go	78.82% <81.11%> (+2.63%)	⬆️
ledger/ledger.go	63.12% <84.61%> (-0.14%)	⬇️
ledger/bulletin.go	93.54% <100.00%> (+0.21%)	⬆️
ledger/metrics.go	100.00% <100.00%> (ø)
ledger/notifier.go	88.57% <100.00%> (+0.33%)	⬆️
ledger/txtail.go	87.50% <100.00%> (+2.99%)	⬆️
... and 16 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b39c66...848dd28. Read the comment docs.

[algorandskiy]

I like the separation of the logic.
In the same time I'm a bit concerned with mixing commit data (offset, base) with context data into deferredCommitContext. I propose to keep them separate: let trackers contribute into commit data by modifying (offset, base) as needed but only setting/getting data from the context in order to have kind of "these data are set by au and used by ct"

[tsachiherman]

I like the separation of the logic.
In the same time I'm a bit concerned with mixing commit data (offset, base) with context data into deferredCommitContext. I propose to keep them separate: let trackers contribute into commit data by modifying (offset, base) as needed but only setting/getting data from the context in order to have kind of "these data are set by au and used by ct"

I've broken a subset of deferredCommitContext into deferredCommitRange, so that each tracker could individually, during produceCommittingTask to create a offset/base. Once all the trackers are doing that, this data structure is available as part of the deferredCommitContext, allowing all the trackers to review it.

[algorandskiy]

Looks good. The only thing worries me is deferredCommitRange is modified by all trackers and there are no restrictions on offset/base change. Maybe some kind "protocol" on modifications is needed otherwise there is a chance some tracker can set the offset way too off for some other tracker. It looks like the range deferredCommitRange wants to be a type with some encapsulated behavior with max/min offset values for this round.

[tsachiherman]

Looks good. The only thing worries me is deferredCommitRange is modified by all trackers and there are no restrictions on offset/base change. Maybe some kind "protocol" on modifications is needed otherwise there is a chance some tracker can set the offset way too off for some other tracker. It looks like the range deferredCommitRange wants to be a type with some encapsulated behavior with max/min offset values for this round.

I didn't want to be too restrictive on what can be done with the deferredCommitRange, as it feels like over engineering. Generally, we want only to narrow down the range as we move along, but given that we have only two parties that really care about that, I couldn't really justify that..