Keep multiple latest confirmed nonces at source in messages relay

[svyatonik]

found this when working on #680

So there's lag before finalized source header H appear at target chain. Relay was reading latest_confirmed_nonce_at_source from best finalized source block. Then it has been using this value to compute number of headers that may fit into delivery transaction and was generating proof of this value at block H', which is best finalized source block, known to target node. If H != H', then the value may also be different => the target chain may have rejected some messages from delivery transaction. Relayer then had to wait for stall_timeout to pass and only then continue its work.

Another change is splitting single target_nonces_updated into best_target_nonces_updated and finalized_target_nonces_updated to maintain this new deque (latest_confirmed_nonces_at_source).

[tomusdrw]

Gave it a brief look, but it looks good to me.

Do I understand correctly, that this simply makes the relayer more resilient to cases where finality is taking a little bit longer to deliver (i.e. we can still send the part of the messages that we are supposed to send)?

[svyatonik]

Do I understand correctly, that this simply makes the relayer more resilient to cases where finality is taking a little bit longer to deliver (i.e. we can still send the part of the messages that we are supposed to send)?

It makes relayer aware that these lags exist - after this PR it'll always deliver maximal number of messages it can deliver. Before: it may have tried to deliver more messages than target chain may accept => some of messages were rejected. This difference was because of finality lagging (I'm talking here about our header chain finality, not the GRANDPA finality)