Deadlock elimination for GetEstimatedTimetoStake()

[jamescowens]

The new GetEstimatedTimetoStake() function has a rare
deadlock situation between the cs_main and cs_wallet locks taken for
a very short time in it and the MinerStatus locked in GetGlobalStatus()
and CreateCoinStake(). ifoggz suggested called GetEstimatedTimetoStake() and
assigning to a local variable right before the critical section in
GetGlobalStatus() to correct the lock order. This appears to work very
well. Wallet against testnet with the change has been running >24 hours without
deadlock.

[iFoggz]

MinerStatus gets locked without any previous locks and/or after cs_main and cs_wallet. due to the need for the cs_main and cs_wallet locks in GetEstimiatedTimetoStake() we essentially reversed the order before. This prevents that this fix will make sure that the data is received first before locking the MinerStatus

[denravonska]

I think we have an overall problem when you have to know the lock strategy for the entire call chain. This makes these kind of problems unavoidable and hard to debug. We're just lucky you caught this one.

Perhaps instead of manipulating the status object directly we do it on a temporary and assign at the end. That way we can keep the locks to a minimum.

globalStatusType status;
status.blocks = ToString(nBestHeight);
status.ETTS = RoundToString(GetEstimatedTimetoStake()/86400.0,3);
...
..

LOCK(GlobalStatusStruct.lock);
GlobalStatusStruct = status;

We can do it outside of this PR though.

[jamescowens]

@denravonska I really like that. Can you merge this one into dev/staging. I will begin working on another one to implement this approach...

[tomasbrod]

• Just do not put the lock into the variable you are overwriting.
• consider using atomic pointer