core/filtermaps: clone cached slices, fix tempRange

[zsfelfoldi]

This PR ensures that caching a slice or a slice of slices will never affect the original version by always cloning a slice fetched from cache if it is not used in a guaranteed read only way.

[rjl493456442]

Should we also clone the slice in getFilterMapRow?

[zsfelfoldi]

We do clone baseRow and if required then we append extRow which is always retrieved from the database so it's guaranteed that the returned result does not share an underlying array with anything.

[rjl493456442]

LGTM

[zsfelfoldi]

The slice cloning, though definitely necessary to be safe, did not solve the issue so I added a lot of debug prints and finally conclusively traced the error back to its origin. When I add a new block and overwrite the last map with a new rendered one, I temporarily use tempRange as the indexed range which excludes the last map that can be inconsistent during the write (unfortunately it can take too long to make it atomic). During this time, even if the matcher did find some potential matches, getLogByLvIndex will not return results for this temporarily invalidated map (and even if it did, the filter logic would trim them as potentially invalid). This is fine, but what I noticed in my debug prints is that the logs of the last fully rendered block in the previous, untouched map are also unavailable during this period, and the mismatches exactly correspond with these blocks.
I added a unit test that reproduces this error by trying to fetch the first and last valid logs of the temporary range from the map renderer callback. It always and easily reproduced the error which traced back to tempRange being invalid. headDelimiter was set to 0 as the indexed view's head is not indexed in this temporary state, but headIndexed was still true. This was an inconsistent state which caused getBlockLvPointer to return 0 for the last, partially indexed block which caused the binary search if getLogByLvIndex to find the wrong block and not find the logs at the requested position.
I believe the cause of this issue has been conclusively determined now, and it was a different issue from the previously fixed one related to the render snapshots. That one caused indexing errors and permanent incorrect results while this one only affected the search results and only happened once if the search coincided with the map write.

[zsfelfoldi]

I also changed getBlockLvPointer to return headDelimiter + 1 instead of headDelimiter for future blocks if the head is rendered; this difference currently does not affect the operation at all but headDelimiter + 1 is the position where the next block will start once added so this is more logically consistent.

[rjl493456442]

Should we error out if blockNumber > f.indexedRange.blocks.AfterLast()?

Theoretically, the returned log index is for the next block and it must be consecutive with the latest indexed one.

[zsfelfoldi]

Since the search works async (range might change any time during the process) the underlying functions of the matcher backend do not fail when they are queried out of range, they just return results so that the search will not find any additional items (the head part of the results will be invalidated anyways in this case). getLogByLvIndex also silently returns with no result end no errors.
getBlockLvPointer also just returns the beginning of the next future block, even if queried further in the future, so that the search will just search until the end of the indexed range. The point is that if it's a long search then the majority of results will still be valuable and the head part will be searched again anyways so just do something that lets the operation finish safely.
We could have a different mechanism but this seems to work safely for now and we have to do the fork release today so I would not change it fundamentally right now.

[rjl493456442]

is it the real root cause?

[zsfelfoldi]

yes