Track milestones by index vol. 2

[jakubcech]

Description

Second part of #1447, where Luca hinted that:

The logic must be smarter for this to work. Consider someone setting up a new node at milestone 0 where the actual current one in the network is 1000. The new node doesn't have the milestones from 0-1000 and there is no way for it to request milestone 1 or 2 from the neighbors as it lacks the data in the db.

So if the logic is simply: "load up all transactions where the index is 1-11", the node won't find any milestone candidates and hence it won't synchronize.

What works is:

Requirements

• If the latest milestone didn't update in 420 seconds - fall back to the old approach to load all txs hashes from the coordinator address (like every 5 minutes and up on startup (with a delay = milestone issuance interval))
• Now the node knows the actual latest milestone
• Use the set of indices from newest milestone in soldification queue to newest milestone in soldification queue - 10 to query the database for new milestone candidates

[jakubcech]

This will likely be deprecated for #1448