simulation: Switch the log method from a single string to string buil…

[ValarDragon]

…ders

This rapidly speeds up simulation in testing mode.
ref #1924

The idea here is basically instead of using a single "log" which everyone appends to all the time, instead have a log builder, which we have a centralized way of writing to/fro. Additionally invariants no longer print out the log, but instead return an error. This enables them to be easily reused / be located elsewhere from the simulation module.

In general it makes the types simulation wants you to make more extendable and easier to understand.

• Targeted PR against correct branch (see CONTRIBUTING.md)

• Linked to github-issue with discussion and accepted design OR link to spec that describes this work.

• Wrote tests

• Added entries in PENDING.md with issue #

• rereviewed Files changed in the github PR explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[ValarDragon]

After 200 it slows down again cuz of the governance slashing issue. But it burns through the first 200 in ~20 seconds!

[codecov]

Codecov Report

Merging #2282 into develop will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #2282      +/-   ##
===========================================
+ Coverage    63.82%   63.83%   +0.01%     
===========================================
  Files          140      140              
  Lines         8668     8666       -2     
===========================================
  Hits          5532     5532              
+ Misses        2756     2754       -2     
  Partials       380      380

[ValarDragon]

Also once this PR is merged, it will be super easy to make simulation print out the log on a panic

[cwgoes]

Huh is this faster than just using a byteslice instead of a string for the log messages? Seems like a possible memory leak to keep so many stringbuilders around.

[ValarDragon]

Using a single byte slice still has the re-allocation problem. (E.g when it's too full you need to re allocate the whole thing). My thinking with this is that it will be easier to then just start to purge these from memory by writing to disk every few blocks, and then deleting that string builder.

[cwgoes]

utACK

[cwgoes]

would that Golang had monads

[ValarDragon]

We can only wish :(

[cwgoes]

Using a single byte slice still has the re-allocation problem. (E.g when it's too full you need to re allocate the whole thing). My thinking with this is that it will be easier to then just start to purge these from memory by writing to disk every few blocks, and then deleting that string builder.

OK!