core/filtermaps: properly handle history cutoff while rendering index head (WIP)

[zsfelfoldi]

This PR ensures safe behavior of the log indexer when head indexing cannot be performed because of history cutoff. Previously only the tail indexing conditions were aware of the cutoff point.
Now if a receipt is missing, the renderer returns errHistoryCutoff in which case the indexer main loop will not reattempt the same thing but instead it will reset the database, triggering a new checkpoint initialization attempt (maybe the database was old but the client has been updated and has recent checkpoints). If the latest checkpoint is also older than the cutoff point then the init function also returns errHistoryCutoff and the indexer goes into disabled state.
Another issue fixed here is that in case of unexpected errors waitForEvent was called which was incorrect because what it really did was that it waited for a new target head and if there was already an unindexed target head then it did not block at all, letting the indexer loop to spin on max speed with the same error, not even noticing node shutdown.

This PR is based on top of #31081 because it also touches the database reset logic which has been refactored in that previous PR.

[rjl493456442]

It's not 100% correct, but probably good enough for the normal cases.

The issue is if the last byte of prefix is 0xff, then the range will be invalid.

// increaseKey increase the input key by one bit. Return nil if the entire
// addition operation overflows.
func increaseKey(key []byte) []byte {
	for i := len(key) - 1; i >= 0; i-- {
		key[i]++
		if key[i] != 0x0 {
			return key
		}
	}
	return nil
}

[zsfelfoldi]

I know but is is never 0xff, it is a constant we specify in schema.go.

[zsfelfoldi]

Fixing the indexing with cutoff sync will take more time and is not essential to today's release so I'll mark this PR as WIP and not targeted for this release.

[zsfelfoldi]

Closed in favor of #31455