Fix light client informant while syncing

[ngotchac]

From #9385 , the informant wasn't displaying correctly the syncing state. This is because the state of LightSync had deadlock issues, and the default to is_major_importing was set to false if the lock couldn't be acquired. This lead to false logs in the informant.

In this PR, is_idle is added, and gets updated everytime the state is updated, such as is_major_importing can check this boolean instead of waiting for state to be unlocked.

[ordian]

I wonder whether there was a reason in #5002 not to take into account verified_queue_size
https://github.com/paritytech/parity-ethereum/pull/5002/files#diff-e8c26f6188b2b873a7467abd3041b843R584
@rphmeier? Although that was a long time ago.

[ngotchac]

Not sure about that. But from my local testing, it lead to wrong information being displayed (Import logs too soon)

[cheme]

LGTM, Basically we are kicking verification queues mutexes and a new mutex instead of the state mutex, that should totally works, and indeed it works well (at least during 4hours when the deadlock happens usually in less than one).
So it is yet another additional mutex, but until a more impacting refacto to reduce those, this PR is very welcome and nice work (thanks for fixing this 👍 ) .

I also did put a short comment with a suggestion (but it is just a suggestion).

[cheme]

I am not really sure about the usefulness of this struct, it seems that set function is only called once in set_state of LightClient, since fields are private.
Ok, I got it, it avoid bad use in future client inner implementation, maybe then we could move is_idle to it:

struct SyncStateWrapper {
  state: Mutex::new(SyncState::Idle),
  is_idle: Mutex::new(true),
}

and keep deref to state. Then we would have an easier set function (without handle ref).
This could be a bad idea if we need to keep is_idle mutex open (does not seems so).

[ngotchac]

The thing is that you want to keep an open SyncState Mutex while is_idle still being accessible. With the suggested changes, you cannot have a lock on SyncStateWrapper (otherwise is_idle wouldn't be accessible), so you would have to expose the inner SyncState lock, which could be used to directly change the state, without updating is_idle. Does that make sense?

[cheme]

Make sense, my suggestion was your second hypothesis (no mutex around SyncStateWrapper) , it does need to exposes the inner lock, on the other hand it keeps both locks together.
There is maybe less chance to mistake with current version, a mistake would be to pass any &mut bool to set_state which would be clearly intentional.