core: repro #18977

[holiman]

This PR adds a testcase to reproduce the crash in #18977. What happens is

1. A chain A has N blocks at td Ta.
2. A sidechain B has M blocks at td Tb. Tb > Ta.
3. However, the B chain consists of a lot more blocks, so that at the point where Tb surpasses Ta, the block number is more than 128 blocks ahead of the head of A.

Todo: @karalabe take it from here and make the test pass.

---

@karalabe: Done.

The issue was that when we import very long sidechains, we only reorg the canonical numbers after we exceed the local chain's TD. The pruner however used canonical numbers to figure out which trie to commit when. Since canonical numbers are unavailable until sidechain import is actually done, the pruner accessed non-indexed headers and crashed.

The fix is first of all to not access the canonical number unless actually needed (only when we want to commit, not during normal imports); and second to handle the case when the header numbering is missing by postponing commit to the next block.

[karalabe]

@holiman PTAL

[holiman]

I'm unable to github-approve, since it's my PR. But you have my approval!

Note:
As you fixed it, it will work. Howver, whenever it's doing a sidechain import, which does not fulfill this low-td-but-long behaviour (that is, a normal sidechain), it will behave somewhat oddly.

• Import sideblock B' number N.
• Perform gc on canonblock B number N. Which it has already done, while importng B.

So this fix addresses the panic, but I think it's still not quite Correct (tm)

[karalabe]

If it does not exceed the TD, it won't process the sidechain, only inject the raw block into the database.

[karalabe]

Btw, I added a tiny extension to the test case so that it also verifies that the canonical numbers are updated after the whole fiasco (just to make sure it's not a deeper bug, just a temporary thing).

[karalabe]

Also I deleted the helpers, modifying the difficulty is already supported (alas a bit convoluted) through b.OffsetTime(-9).