Remove epoch accumulator history network content type

[njgheorghita]

There has been some discussion in Discord regarding whether or not it's worth storing epoch accumulators in the network. I've listed some of the main points below, but please add any other relevant points.

Pro (aka. let's remove the accumulators)

• Nobody on the network is currently using this data
  • Bridges keep a local store of the accumulators (to build proofs)
• It uses up wasted network storage/bandwidth
• Requires extra work - eg. tooling support (glados / portal-hive / etc..)

Con (aka. let's keep them in the network)

• It may be useful to support block_hash by block_number lookups (for pre-merge blocks)

[njgheorghita]

Personally, I'm in favor of removing them for the time being. We don't have a current use case. It will not be difficult to re-introduce the content type once the use-case is fully justified.

[KolbyML]

Removing EpochAccumulayors takes time away from debugging real issues making our network unstable.

Our bandwidth bottleneck has to do with us sending 2 udp packets for every 1 uTP packet. uTP packets are sent over TalkRequests which requires a talk response. This is our biggest networking bottleneck and also a very low priority.

Removing it takes dev time what can resolve issues stopping us from launching a 4444's network.

I am not sure how this PR relates to the MVP Milestones. This seems like a side quest we should talk about in 6-12 months

[KolbyML]

Currently nobody uses the network. So of course nobody uses it yet. Have gotten confirmation from fluffy that they already use it.

With how I wrote NClientTestSpec and test creation automation on Portal Hive it would take 5-15 minutes to add tests for EpochAccumators the hardest part is me getting the content key/value myself which would be using logs to dump it from the bridge

[njgheorghita]

Have gotten confirmation from fluffy that they already use it.

Yup, closing this issue.