Fix fork choice rule to prefer the heaviest chain

[nazar-pc]

Previously we were deriving block weight from solution quality, which was actually wrong, it should have been derived from corresponding solution range instead.

Also in case node is presented with two forks that have the same weight, it'll now prefer the first block seen, rather the higher block number.

Resolves #1505

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

@vedhavyas I forgot to update fork choice rules in sp-lightclient which caused tests to fail. If you ignore whitespace changes, changes are quite straightforward. I also reused the function to compute weight, logic was duplicated in sp-lightclient, if it wasn't, it would fail to compile from the beginning.

I have renamed test_chain_reorg_to_longer_chain to test_chain_reorg_to_heavier_chain, but then also noticed it is not actually doing reorgs, it just extends existing chain. Did you mean to do it like that? I see that the chain is not marked as longest, but when I read reorg, I expect switch from one tip to the other tip, typically the same height. In that test we have one branch only.

[vedhavyas]

I have renamed test_chain_reorg_to_longer_chain to test_chain_reorg_to_heavier_chain, but then also noticed it is not actually doing reorgs, it just extends existing chain. Did you mean to do it like that?

It seems to re-orgin as expected. In the test here it will create a fork chain at block height 5 till height 8 but not the canonical yet.
And we confirm that here and there are indeed two forks at that height.

Then we extend the fork by another block, height 9, here. Notice the is_best parameter is set to true so that add_headers_to_chain will make necessary overrides to make block 9 win the forck choice rule and there by becoming best header. We verify that here and also ensure there are no forks at block 5 which would be finalized as per K-deep rule.

[nazar-pc]

I have missed hash_of_5 somehow when reading it, thanks for explaining!