grandpa: cleaner RPC API for proving finality

[andresilva]

In #6215 we introduced an RPC API for proving finality of arbitrary blocks by using the existing FinalityProofProvider infrastructure but the current API is rather cumbersome to use. The existing API is:

fn prove_finality(
  begin: Hash, 
  end: Hash, 
  authorities_set_id: u64,
) -> Option<Vec<FinalityProof>>>;

It requires that a user of the API keep track of the authorities set id and also of block ranges spanning a given set. I think we should be able to implement the following API:

fn prove_finality(block: Hash) -> Option<FinalityProof>;

The way this API would work is that it would always generate a finality proof based on the justification from the last block in the set (which is always guaranteed to be persisted).

If a user wants to prove finality for block #52 we figure out what the set id is for that block and what the last block in the session was. Then we have all the data needed for FinalityProofProvider to generate the proof. I think the only thing we need to do is to start persisting the block number of the last block of the authority set so we get a Vec<BlockNumber>. Given any block number we could then perform binary search on this array to figure out what the last block in the set was (and implicitly the set id given by the index in the array).

For some service that is trying to sync and check for finality they would:

• prove_finality(#1), for which they would get a finality proof that proves finality of all blocks up until the last block in the set;
• this proof will include all of the block headers, so they can just import them if needed (although it might make sense to make the inclusion in the proof optional and just provide block hashes);
• they will also now be able to tell what the first block in the next authority set is (i.e. last block in previous finality proof + 1);
• they loop this process until they get None finality proof, which means they'll be on the latest authority set;
• afterwards they can start listening to the live justifications using the pubsub API.

[andresilva]

We should also think about what it makes sense to provide in the proof for this purpose, rather than just re-using the existing FinalityProofFragment.