Make dispute-coordinator more robust with regards to runtime errors

[eskimor]

We had problems in the past with the RollingSessionWindow in the dispute-coordinator, resulting in it not working properly - while at the same time backing continued to work.

We should make usage of RollingSessionWindow at least as robust as backing - meaning if backing works, dispute-coordinator has to work as well, everything is unacceptable.

In particular this means, it has to be possible to trigger disputes in the current session, even if fetching the SessionInfo for some older session fails.

[eskimor]

Same is true for approval-voting actually. If backing is possible for a particular block, approval voting has to work as well.

[eskimor]

In general, we should make it as unlikely as reasonably possible that disputes/approval voting for non finalized blocks fails. Are there any other calls that might fail? -> Double check.

[eskimor]

• rolling_session_window should be altered to not be 'all-or-nothing'.
• The window should 'stretch' to all sessions we can get, with pruning only done when the session is guaranteed to no longer be needed (i.e. finalization of expiry) Keep sessions in window for the full unfinalized chain #6054
• Persistence to the DB as another layer of safety in the case of restarts

Persistence makes sense, because runtime only keeps x sessions - so even without block pruning, eventually it will get rid of old sessions. So for very long finality stalls (or not soo long on test networks), this will be a problem.