Clean up memories when syncing

[HoOngEe]

The commits in this pr piled upon the #1567
It closes #1576

[sgkim126]

@HoOngEe Would you shrink targets too?

[HoOngEe]

Before shrinking targets the memory usage reduced from about 9.0GB to 5.3GB.

[HoOngEe]

I ran memory profiling tool valgrin --tool=massif, used massif-visualizer and got the following graph.

This time I got data of only 68000 blocks synchronization. So I cannot certain that the data from these two key parts: header_queue of importer, downloaded of HeaderDownloader would be shrunk later. The running time increased about 20 times before attaching heap memory profiler so that I cannot observe in full-time domain. Now I'll check header_queue and body_queue

[HoOngEe]

We have to shrink processing: RwLock<HashMap<H256, U256>> in VerificationQueue also.

[HoOngEe]

I got a full-time synchronization data through last weekends.

The purple area, which was allocated in the block_header_data of HeaderChain implementing HeaderProvider, accounts for almost memory uncleared even after synchronizing old blocks.
It uses HashMap named header_cache internally. But there is no entry clearing routine for this.

[sgkim126]

@HoOngEe I know still there is a memory to cleaning up. However, I think it's hard to fix the problem, there is no apparent time to clean the cache. It should change the implementation to LRU like implementation.
So I propose to merge this PR and keep #1576 open until we fix the memory issue completely.
How about you?

[HoOngEe]

@sgkim126 Ok, let's merge this pr now and fix the cache implementation later.

[sgkim126]

Please remove WIP tag when you think it's ready to merge.

[sgkim126]

This seems redundant.

[HoOngEe]

Yes, It's redundant. I fixed it. Thank you.

[sgkim126]

@HoOngEe LGTM. Please apply it to rc-1.4.0 too.