light tests: remove assertions about number of bisections

[liamsi]

Quickfix that closes #276 (I had this change uncommited in my workspace and just pushed it)

• Referenced an issue explaining the need for the change
• Updated all relevant documentation in docs
• Updated all code comments where relevant
• Wrote tests
• Updated CHANGES.md

[codecov-commenter]

Codecov Report

Merging #295 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #295   +/-   ##
======================================
  Coverage    30.8%   30.8%           
======================================
  Files         129     129           
  Lines        4893    4893           
  Branches     1549    1549           
======================================
  Hits         1511    1511           
  Misses       2297    2297           
  Partials     1085    1085           

---

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 b881142...547d714. Read the comment docs.

[romac]

Should we remove the field from the JSON as well?

[liamsi]

Should we remove the field from the JSON as well?

The JSON is generated from the go-code. I wouldn't manually remove it here but let @Shivani912 change the generator code and re-generate the JSON files instead (which is kinda orthogonal to this PR).

[greg-szabo]

I've got to learn more about bisections and why different implementations would require such different number of bisections but this change in itself is fine. You're removing unused code.

[romac]

@greg-szabo: I've got to learn more about bisections and why different implementations would require such different number of bisections but this change in itself is fine. You're removing unused code.

@josef-widder touched on that in the verification spec:

Schedule decides which height to try to verify next. We keep this underspecified as different implementations (currently in Goland and Rust) may implement different optimizations here. We just provide necessary conditions on how the height may evolve.

As an example, an implementation of Schedule could realize that, even if the optimal block to bisect to is of height H, there is already a block of height H+N (for a small N) in the store, and decide to pick this one to avoid fetching block H over the network. This could lead to a different number of bisections.