Add get_header_by_hash client method

[randomlogin]

Allows client to retrieve block header by its hash.

Motivation: when we listen for kyoto events, we receive Event::IndexedFilter which has only height value there. By the moment we process this event, the header chain could have reorganized from the canonical chain, and when we retrieve the header, we actually retrieve a stale one.

Right now we can just check if retrieved header is the right one, but we cannot get the right header via hash.

[rustaceanrob]

IndexedFilter contains the block hash as well. Is it possible to just check if this block hash has been reorganized? I am also why the disconnection event is insufficient to undo any changes.

[randomlogin]

I think you're right and even if a consumer receives IndexedFilter event and can no longer find block hash from the event, it means we're going to receive reorganization event soon and we can skip the current event.

However I've just realized there can be a bug when we reorganize from longer chain with less amount of work: if we are at block 110 and we reorganize to another chain with the tip at block 105' (but with more work), then when we call get_header(108) we would receive a block not from a canonical chain. Of course the question is why anyone would ask for this header in the first place, but maybe it's worth noting somewhere.

    fn switch_to_fork(&mut self, new_best: &Tip) -> (Vec<IndexedHeader>, Vec<IndexedHeader>) {
        let mut curr_hash = new_best.hash; //we go from the new tip which might be of lower height
        let mut connections = Vec::new();
        let mut disconnections = Vec::new();
        loop {
            match self.headers.get(&curr_hash) {
                Some(node) => {
                ...

[rustaceanrob]

It should not be possible to be on a longer chain that has less work in practice. We audit that the difficulty adjustment is adhered to, so all blocks will be approximately the same work given a block height.