Improve relay chain header selection algorithm

[svyatonik]

Right now batch relayer uses following strategy for selecting relay chain header H or its descendant: it simultaneously (1) starts reading finality notifications from the stream and once proof for the H or its descendant found, yields (2) starts searching for the persistent justifications, starting from H and once persistent justification is found for H or its descendant, yields.

This is to decrease bridge latency. However it brings some inconveniences - e.g. it is hard to read set_id from the source chain (see #2821) because for block, justified with persistent justification the state may be discarded, so we need to use some tricks to guess the set_id (e.g. read at latest block + start incrementing best set_id until justification is verified). It'd be good to have a way to know the id of set that has generated justification to check it explicitly in the relayer code. Now we rely on the verify_and_optimize_proof to verify justification using set_id, read from the target chain. It may cause some side issues (e.g. #2394).

Maybe we should prefer justifications from the subscription stream, but if we fail to get justification for some time (e.g. 12+ seconds), start searching for persistent justifications too. Need to think what is better here

[svyatonik]

Not actual with #3002