client update inefficiency with multiple relayers

[rnbguy]

Currently, the trusted height of the sovereign light client header must be the latest height at the stored client state.

https://github.com/informalsystems/sovereign-ibc/blob/43de9b2fa02a35def46b2284b826ce9e4095fa7e/clients/sov-celestia/types/src/client_message/header.rs#L93-L98

This was required because the zk-prover didn't have recursive support. So, the sov component of the headers must be consecutive. Recently, recursive support was added to the zk-prover. Now, the header updates can skip intermediate slots.

Considering this new change, the above restriction creates inefficiency with multiple relayers (race condition). If relayer-A and relayer-B are trying to update the latest slot height 2 to slot height 4 and 5, respectively, only one of them will succeed. Whichever transaction goes first will update the latest slot. This fails the second transaction, as it will not have the updated trusted height. So, the failed relayer has to regenerate the client update for the updated slot.

Therefore, we can remove the above restriction to allow non-sequential light client updates - similar to native Tendermint light client updates - where the trusted height can be any previous height with an accepted consensus state.