Issue: When launching a new Bisq instance (i.e. new data directory) and
remaining on the user agreement screen for >90 seconds while reading it,
once you accept the agreement the BTC status was not being shown
on the splash screen.
Cause: showTorNetworkSettingsTimer gets triggered after 90 seconds
and since Tor is not started until after accepting the user agreement,
it was incorrectly assuming that Tor is not working and as a result
hiding the BTC status.
Fix: Don't hide the BTC status in showTorNetworkSettingsTimer. If there
is an issue with Tor, splashP2PNetworkErrorMsgListener handles
hiding the BTC status.
To avoid that the UI gets frozen at batch processing of blocks we
delay each parsing to the next render frame. The total parsing time is
just about 5% slower that way but the UI can render updates.
We also changed the hash for the daoState as the hashing of the full
state becomes quite heavy. The size of the blocks is about 1,4 MB for
7000 blocks (dao testnet). As on a new block only the last block in the
chain got added and as we use the previous hash in the hash chain we
do not need to hash the full blocks list but only the last block.
By that we decrease batch processing time from 30 sec to 7 sec. and data
size of the daoState from 1,4 MB to 200 kb.
Also added progress display of missing blocks in the Tx UI.
Changing validation rules can potentially break consensus (e.g. a past
proposal has been accepted according to old rules, and might become
invalid by new rules. The result of the proposal would become
invalidated then.
To be able to apply the validation also on past cycles we need to use
the block height if the proposal tx and not the current one. Just in
case the tx is not confirmed (when temp proposal gets published) we use
the current height, but that would anyway match the cycle.
In a past cycle params could have been different and validation need to
use the correct param value from that cycle.
We used ProposalValidator for most validation processes but that missed
the custom validation in the sub classed for each proposal type.
ProposalValidator is now abstract and ProposalValidatorProvider returns
instance matching to proposal type.
