Majority without gaps

[tbekas]

Resolves #1497

• Majority should not have gaps
• Majority should always overlap with the previous majority
• Missing proposals are getting looked up only if the majority stalls for 4 consecutive rounds or more
• Lookup range of missing proposals changed to [+2, +8] (relative to latest majority height)
• Replacing MajorityInfo with CuckooFilter
• Adding endpoint POST /snapshot/proposal/_query

[TheMMaciek]

I'm not sure if we should just remove proposals based on our calculated majority. In case someone else gets stuck because of a missing proposal, we may not have that proposal anymore at the time when the node will be asking for it. I would take into account the filter and check if all other nodes have that proposal present/majority picked at certain height and only then remove it.

[tbekas]

We store at least 40 heights of proposals, a node that is 30 heights below or more would start redownloading itself already before we would remove any proposals he may need. These parameters could change, but implementing this would introduce just more complexity and with the current config, that complexity would never be used. Also, another case is what if someone doesn't have proposals at all, should we keep all of them indefinitely? If so memory leak, so another case to handle.

[TheMMaciek]

I get your point. If you think it's too much hassle and no gain then there is no point in implementing that indeed. Especially if the logic right now is sealed e.i. all the cases are handled and we won't have nodes continuing ahead indefinitely - in consequence the redownloads will work as intended.

[tbekas]

Already merged to dev