Small tweaks to the LoE

[Niols]

This PR is a cherry pick of the commits of #1119 that make changes to the LoE:

1. We relax the bound in computeLoEMaxExtra in d32239b. Previously, this function could never return Just 0. This made the LoE stricter than necessary. This is not a big problem but it does not match the modelled behaviour.

2. Instead of rejecting candidates that fork off the LoE fragment, we now trim them in 3957238. This is again just relaxing the LoE a tiny bit.

3. We change the helper followsLoEFrag in c6b1d22. It previously had a pre-condition that the anchor of the candidate had to be somewhere on the LoE fragment, but this precondition was regularly violated. The new version does not have this shortcoming.

[Niols]

This force push addresses your two comments (getting rid of the changes that introduce a bug and then fix it, and merging two commits). Additionally, it adds a681653 (from #1119) to what is now bfd27d0.

[amesgen]

We don't actually need the ledger, so maybe just pass in the fragment?

[Niols]

That is true, but that would actually be more verbose to use in addToCurrentChain and switchToAFork so I'd prefer keeping it like this. Alternatively, to make the use of arguments clear, we could have followsLoEFrag (now trimToLoE) getting only a fragment and then a variation followsLoEFrag' that gets a ChainAndLedger and a diff, turns it into a fragment, and passes it to followsLoEFrag. Only the latter would actually be used in code.

[facundominguez]

I went into the trouble of pruning the generation of candidates instead of trimming.
niols/fix-loe...fd/no-trimming

I find the code easier to understand since there are no subtle interactions between generation and trimming. But Uniform tests are failing still.

For May I propose that we deliver this PR more or less as is, or perhaps without the trimming. Then we can try to polish the code for July by tuning the generation of candidates.

I'll see if the trimming is noticeable in benchmarks. I'm guessing that the intersections could be noticeable in the 1 peer case of syncing, when chain selection dominates execution time.

[Niols]

I went into the trouble of pruning the generation of candidates instead of trimming. niols/fix-loe...fd/no-trimming

I find the code easier to understand since there are no subtle interactions between generation and trimming. But Uniform tests are failing still.

I had the exact same experience when I tried this, although my changes to maximalCandidates were different.

For May I propose that we deliver this PR more or less as is, or perhaps without the trimming. Then we can try to polish the code for July by tuning the generation of candidates.

I think that is wise.

[facundominguez]

There is a small overhead to trimming. But it doesn't seem to delay syncing or not by much in any case.

10 peers, trimming:
trimToLoE:   0.475s  count:  2_443
real 4m5s

10 peers, no trimming:
followsLoEFrag:   0.293s  count:  2_442
real 4m16s

1 peer, trimming:
trimToLoE:  24.728s  count: 5_393
real 8m10s

1 peer, no trimming:
followsLoEFrag:   0.267s  count: 2_436
real  8m10s

[Niols]

Bundled everything into one commit and rebased on top of genesis/milestone13.