feat: reduce the extra data used for block headers that aren't relevant to the client

[tomyrd]

for a client that is online and syncs very frequently with the network, we may end up storing a lot of extra data. Ideally, if a block header doesn't have relevant notes, we shouldn't store it, unless it is the last block in the chain. Thought, I wonder if this has any implications.

Originally posted by @bobbinth in #650 (comment)

[igamigo]

During a sync, we need to keep the MMR up to date but I don't think there are bad implications to not storing block headers as long as we always keep the last one in the chain. Of course this would build up to having multiple block headers just because they were the chain tip at some point and not because they were relevant to the client, but it would be an improvement (and those blocks could be cleaned up eventually). The other option, I think, would be to just store the hash for those headers that are not relevant to the client, but this involves complicating the store's API a bit.

[tomyrd]

Another edge case to keep in mind are imported notes, these may make some blocks relevant that weren't before. Although, we have a way to deal with those in Client::update_mmr_data.