Finality votes cache

[svyatonik]

attempt to solve (1) from #78 (comment)
on top of #105

This PR adds persistent finality votes cache. It doesn't change computational complexity of headers finalization algorithm, but instead significantly decreases current implementation overhead. I.e. if number of unfinalized headers is N, then we still need to cycle over N headers, but instead of making N storage reads, we only need to perform limited number of reads (though at least one of these reads may read larger number of bytes than regular header - see below).

We still need to introduce 'spanned finalization' (mentioned in #78 (comment)), but I think for now (I mean for initial start) the cache should be enough. On the same 1926 unfinalized Kovan headers from #78, I'm now getting time(import(header#1926)) / time(import(header#1)) ~ 6.5 instead of previous ~46.5.

The cache now works as follows:

1. when header N is inserted, we're building struct FinalityVotes, that includes info about all unfinalized ancestors of this header (note that it isn't header itself, but some shortened version);
2. if N % FinalityVotesCachingInterval == 0 then we're inserting this structure into finality cache;
3. when next header N+1 is inserted, we will only need to read header N and this struct;
4. if nothing has been finalized yet, then at N+2 we'll read two headers (N+1, N) and the same struct;
5. ...
6. at header N + FinalityVotesCachingInterval we'll insert another entry into finality cache;
7. at header N + FinalityVotesCachingInterval + 1 we'll again need to read only one header (N + FinalityVotesCachingInterval and that struct).

The cache itself may be improved later, e.g. by not inserting entries if finalization is regular (i.e. we do not have large delays) or by making bridge guess FinalityVotesCachingInterval on its own (i.e. we know number of validators and we know we need votes of 2/3 validators => so having 2/3*len(validators) + regular_finalization_delay unfinalized blocks may be a good criteria for enabling cache and initial caching interval).

The cached struct has approximate size of NUM_VOTED_VALIDATORS*28 + NUM_UNFINALIZED_HEADERS*81. E.g. if 5 validators have authored 1000 unfinalized blocks, then the size would be ~80K. This is rather large storage entry, but: (1) it is much better than reading 1000 headers and (2) I'm not sure if we'll be able to get rid of this struct even in 'spanned finalization', because we'll need to cache computation results somewhere between continue_finalization() calls.

Performance comparison on initial Kovan headers: before this PR vs after this PR (native execution, debug build).

[tomusdrw]

Why is it on top of #105 ? Is there a specific thing required from that PR? Maybe split it into two then or ping us to review #105 :)

Reviewing "on top" PRs is really super hard (read: impossible) and after we squash-merge #105 there's going to be a mess with commits which also makes it a bit harder to grasp your intentions (by looking at individual commits).

[svyatonik]

1. It actually uses stuff from Use runtime storage in PoA -> Substrate module tests #103 - will rebase on top of it instead;
2. I'm not willing to push/ping anyone for review - I feel uneasy about it;
3. the simplest solution is not to squash, no? Right now this PR has only one commit - if I'll add any other significant changes, I'll left a comment here.

[svyatonik]

It should be ready now. This PR only adds commits >= finality cache.

One last thing that I wanted to mention is that now PoA headers are mostly referenced by HeaderId { hash, number } both when in storage and in memory. This may now seem redundant almost everywhere, except for StoredHeader::last_signal_block. But there (and maybe later in other places) it helps to resolve header.number by header.hash without additional storage reads.

[tomusdrw]

lgtm!

[tomusdrw]

Worth adding a custom Default implementation to simplify creation.