[Validation] Synchronous update for CDeterministicMNManager::tipIndex

[random-zebra]

As this has direct consensus implications, it cannot be updated in the background thread (in fact, the tests must pass without having to resort to SyncWithValidationInterfaceQueue).

The manager's tip must be updated on the caller's thread and, on the other hand, what is being called by UpdatedBlockTip (on the background), such as CActiveDeterministicMasternodeManager::Init or CActiveDeterministicMasternodeManager::Reset, shouldn't rely on the manager's tip, but use pindexNew instead.

[furszy]

Concept ACK, nice catch the CActiveDeterministicMasternodeManager:Init/Rest issue 👌 .

---

Have been investigating the not found DMN payment failure reason, and is because the cached index inside the manager is from the previous block (not the tip) when the test calls to GetListAtChainTip in the payments verification loop.

Better to move the dmn manager tip update call to the bottom of ConnectTip (where we have the other MN manager tip update calls). Which will slightly modify the process as the function will be called synchronously for every connected block in the main-chain and not, as is now, only at the end of the chain activation process to signal the tip.

I have run this patch furszy@1ba46ae over 200 times and it did not fail again for a not found DMN payment.

Aside from that, the duplicate operator key issue still happens. Which seems to be unrelated to this first problem as it's much more inconsistent (at least locally), have seen it only once in a consecutive 200 times test run.

[random-zebra]

Aside from that, the duplicate operator key issue still happens. Which seems to be unrelated to this first problem as it's much more inconsistent (at least locally), have seen it only once in a consecutive 200 times test run.

Yeah. This was caused by a bug in the bls-signatures library (fixed here: PIVX-Project/bls-signatures#11)
In the meantime we can bypass the issue by using the move operator in the test, instead of copy-assignment, which is even better in this case (bcdb4f0).

This PR is ready for review now.

[furszy]

Can rebase it on top of #2650 if you want now :).

[random-zebra]

No need to. The move operator is fine, and this particular issue wasn't really even related to the changes here.
We can merge the two PRs separately.

[furszy]

code ACK with some comments.

An extra point would be to rename the DeterministicMNManager::UpdatedBlockTip function so we don't get confused by the validation interface signal function that has the same name and a different workflow (sync call vs async call). Getting older and tend to forget things like this easily..

[furszy]

awesome to see this PR finally passing 😄, ACK 55588dc