use CBlockIndex* insted of uint256 for UpdatedBlockTip signal

[jonasschnelli]

• removes mapBlockIndex find operation
• theoretically allows removing the cs_main lock during zqm notification while introducing a new file position lock

[dcousens]

utACK

[promag]

I choose uint256 because I don't know the ownership, thread safety and lifetime of CBlockIndex* objects.

Otherwise LGTM.

[sipa]

They have infinite lifetime. Some fields are mutable (especially validation state and disk offsets), but even CBlockIndex::GetAncestor can be used without locking.

[dcousens]

@sipa didn't that invariant change with pruning?

[sipa]

Since pruning, the disk position information can go from existing to nonexisting, but otherwise, nothing chamged. CBlockIndex entries still live forever, and their pprev, pskip, chainwork, block hash, difficulty, timestamp, height, ... are still immutable.

[dcousens]

@sipa ah, so that was what could change in #6688?

[laanwj]

This makes sense. If there comes a time that CBlockIndex* are no longer infinitely kept in memory, we need to replace them with another handle type throughout the code, and this change will not be a specific blocker.

utACK.

[sipa]

I think ReadBlockFromDisk should grab cs_main by itself, only when read the disk position information, and release before actual reading. That way, the publisher doesn't need access to cs_main anymore.

[dcousens]

Agreed with @sipa, do the existing locks allow for recursive locking? Or would we have to re-write a lot of that code?

[sipa]

The sync.h locks support recursive locking.

[jgarzik]

+1 on not holding across disk I/O

[jonasschnelli]

@sipa: do you prefer adding the cs_main lock to ReadBlockFromDisk() within this PR?
I personally would recommend to keep this PR as it is and address the ReadBlockFromDisk() cs_main lock in another PR because it might need some adaptation here and there.