Fix nil handling

[wmitsuda]

A regression was introduced as part of #10402 during files merge process where a nil pointer can crash erigon.

INFO[05-27|15:38:55.343] [snapshots] state merge done accounts(val:148-150, hist:148-150, idx:148-150), storage(val:148-150, hist:148-150, idx:148-150), code(val:148-150, hist:148-150, idx:148-150), commitment(val:148-150)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x103324dfb]

goroutine 832220 [running]:
github.com/ledgerwatch/erigon-lib/state.(*Aggregator).integrateMergedDirtyFiles(_, {{{0xfc002088040, 0x2, 0x2}, {0xfc002088070, 0x2, 0x2}, {0xfc0020880a0, 0x2, 0x2}, ...}, ...}, ...)
        github.com/ledgerwatch/[email protected]/state/aggregator.go:1526 +0x23b
github.com/ledgerwatch/erigon-lib/state.(*Aggregator).mergeLoopStep(0xc001a12200, {0x10530cca8, 0xc001a0c910})
        github.com/ledgerwatch/[email protected]/state/aggregator.go:685 +0x76a
github.com/ledgerwatch/erigon-lib/state.(*Aggregator).MergeLoop(...)
        github.com/ledgerwatch/[email protected]/state/aggregator.go:697
github.com/ledgerwatch/erigon-lib/state.(*Aggregator).BuildFilesInBackground.func1.1()
        github.com/ledgerwatch/[email protected]/state/aggregator.go:1632 +0x11b
created by github.com/ledgerwatch/erigon-lib/state.(*Aggregator).BuildFilesInBackground.func1 in goroutine 748468
        github.com/ledgerwatch/[email protected]/state/aggregator.go:1625 +0x4d3

[AskAlexSharov]

seems we never use filesItemI.i field. let's remove filesItemI class and use *filesItem? (and we will need nil-check)

[wmitsuda]

seems we never use filesItemI.i field. let's remove filesItemI class and use *filesItem? (and we will need nil-check)

hm, true, will remove it

[wmitsuda]

actually, we can remove the extra struct, but need to leave it without the nil check as pre-refactoring, because integrateMergedDirtyFiles rely on being called even if []*filesItem is nil depending on what comes in the in param.

[wmitsuda]

also, do you still need the startJ return value in staticFilesInRange? if not, it can be dropped as well, I can't figure out what that means, I guess it was some legacy debug return value

[wmitsuda]

startJ seems to be propagated up to SelectedStaticFilesV3.dI, but seems unused there as well

[awskii]

Confirm that we having *I abandoned fields

not allowing to merge with another review

[wmitsuda]

Confirm that we having *I abandoned fields

thanks, will do another PR to remove remaining *I fields and dropping startJ returns in order to make the current code clearer.

[AskAlexSharov]

startJ - I don't remember. if it's unused - then unused.