core, eth, ethstats: simplify chain head events

[karalabe]

Chain events currently pass blocks everywhere. Which is funky, because the first thing all receivers do is extract out the headers and throw the block away :). This PR changes all the event content to only pass the headers around.

Open quetsions:

• We don't use the ChainSideEvent for anything. Can we drop it? I dropped it in the second commit.

Reverted the below change until we figure it out:

• We only use ChainEvent in the filter system, but why don't we use ChainHeadEvent instead? Can we drop it? I dropped it in the third commit.
  • The side effect here is that when importing a batch of blocks, there will be no head events emitted for individual ones, rather only one for the entire batch. This might be a breaking API change, though it is how we ourselves use Geth internally, so maybe it's better to have the same events on the outside too.
  • Even this needs maybe a thought, since batch imports of blocks via the downloader isn't a true chain head event as there was no ForkChoiceUpdate from the consensus client. Wouldn't it be better to only fire chain head events that we receive from consensus? Seems maybe saner?

---

This is the crux of the PR, the rest is just fixing up the fallout:

[MariusVanDerWijden]

Are we emitting these chain events in the downloader on snap sync as well? If so I would vote to remove it, if it is only on full sync, I would kinda understand that it could be useful for someone, but still the usefulness is so marginal, that I would remove it

[holiman]

I agree about removing the heavy blocks, and reducing the subscription throughput. But then I'm not a consumer of these subscriptions, and can't really say whether this will break someone's usecase.

[holiman]

@fjl any thoughts?

[karalabe]

I've reverted the last commit until we figure it out. The rest of the PR is essentially a noop cleanup. It is not observable from the outside in any way shape or form.

[holiman]

LGTM