prune or re-encode activesets from previous epochs

[dshulyak]

stored activesets are ~530MB, while total db size is 1.4GB.

they contain a lot of duplicate data, so there is an opportunity to dedup them, either on gossip or on database level:

• delta encoding. reference to original activeset plus new/removed ids
• store single collection of ids in the epoch ordered by receive time, every new activeset stores bitfield with 1 for atxs that it has in its own activeset

the simplest would be to prune it, Iddo shared that we may want to wait with that:

About pruning, the only reason that it might not be ok is if we have protocol rule that measure the median observed total weight. What Tal described in the call about not rewarding if the active set weight is too small (but above the hardcoded minimal weight) was about ephemeral data, but we also have ongoing discussion regarding how to prevent DoS attack (regarding if your own weight is too low in the far future after genesis, and this issue of observed weight is relevant in this context too). So we should be careful before deciding to prune active sets (deduplication is benign and we should do it asap).

it is caused by unreliable propagation of atxs. expected to get improved by #5097 . so need to recheck it in next epoch