…sn't done.

plus decrease the possible mn list sync request time to 1 hour instead of 3.

…m different peers in case of needing it.

In the previous flow, if one of the requests failed for an already asked sync request (blocked period) or any other issue, the sync requests to the peers that come after it, in an ordered list, were never done.

Before, once the first budget sync message was received, the complete budget sync requests were blocked for the entire peer's life cycle.
This modifies the behaviour to block it only for an hour after the budget sync request reception.

…roposals, request proposals' votes as well.

…and document masternode-sync process.

…st sync" DoS validation.

And decrease DoS penalization to 20 for now (this will be totally erased on v6.0).

…sync process is completed.

…hen the item is received.

The inv item is stored forever in the set.. which will grow infinitely with all the asked for INVs and block any possible subsequent request.

Performed after a chain + tier two data removal.

added 15 more proposals to have a higher network movement in the test.

…addr isCompat function.

…ode addr that causes a signature verification failure.

…c issue.

The mnb can easily be invalid, it's arriving from the network

…rtup.

Added the following changes:
1) Do not accept txs nor tier two INV messages during IBD (with only one exception).
   None of the received data can be validated without be synced with the chain.
2) Only accept sporks during IBD, they are always welcome.

…phase.

It simply makes no sense to relay mnb, votes, proposals, etc. to the peers from where we are synchronizing our initial state while we are doing it.

As they are not totally connected to us, if we send any INV msg they will raise the DoS scoring.

We already have it, no need to continue requesting it to anyone else.