fix long sync cache

[almogdepaz]

Purpose:

only warmup the cache at the forkpoint

this pr pulls the cache warmup up to the sync_from_fork_point call and avoids calling the warmup on each batch

Current Behavior:

we currently dont add blocks that we already know during reorg long sync that means we need to load these blocks each time from the db

New Behavior:

add blocks that are already known so we dont have to warmup the cache each time, this is ok since we clean the cache up to BLOCKS_CACHE_SIZE after each batch

Testing Notes:

since we use add_block in the tests for big reorg we need to manually warmup to the forkpoint before looping and adding each block

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

File	Coverage	Missing Lines
chia/full_node/full_node.py	38.5%	lines 1063-1064, 1068-1073

Total	Missing	Coverage
20 lines	8 lines	60%

[almogdepaz]

our reorg tests use a chain the forks beofre the second sub epoch, that means the fork point will always be 0, coverage failing since we dont test reorg cases where fork point is not 0

[arvidn]

nice!

[arvidn]

the tests I made intended to reorg from a non-zero height, but I think there's a quantizing effect of reorging from the nearest epoch, or something like that. Is that right?
Would the tests need to for from a greater height?

[almogdepaz]

the tests I made intended to reorg from a non-zero height, but I think there's a quantizing effect of reorging from the nearest epoch, or something like that. Is that right? Would the tests need to for from a greater height?

in long sync we find the fork point using only the sub_epoch_summary list (from the wp) we compare the sub_epoch_summary lists and we start syncing 2 sub epochs to avoid forking attacks in the last common sub epoch

i think your change to test-cache should be more then enough but if we changed all the forked chains in the test-cache we might be missing the forkpoint == 0 (unless theres an explicit test for that)

[pmaslana]

@arvidn @almogdepaz Are we good to remove the coverage-diff label? I am assuming so due to the comment regarding the fork point, but I wanted to verify first.

[arvidn]

@pmaslana actually, I'm working on a patch against this PR to extend the test coverage

[arvidn]

@pmaslana extending the tests will take a bit longer than I thought. I think it's OK to land this first. I will follow up with my additional tests.