Replace RollingSessionWindow
with existing RuntimeInfo
cache #6812
Description
RollingSessionWindow
keeps causing issues.
Instead of just requesting (and caching) sessions based on a given relay parent (usually of some candidate), we just grow a session window based on active leaves updates. This mechanism proved to be less reliable. In particular for example on startup we will be requesting the older sessions of the window based on a head that is in a much younger session. While in theory this should work, it does not always because of runtime upgrades and migrations/timing (bugs).
Contrary, with the classic approach of requesting sessions based on a relay parent in that very session, we don't even need the runtime to support queries of historic sessions. The only downside is that this only works for non finalized blocks, but we also only care for non-finalized blocks. In addition the query will very likely be cached by the runtime-api subsystem so it usually will even work for already finalized blocks.
Another reason the rolling session window is more fragile is that the window needs to be continuous, it does not support holes - hence if a single session fetch fails, none will be retrievable -> it will not try fetching more recent sessions (which are usually more relevant) if fetching of an older one fails for some reason.
In order to make sure the cache is populated in case we need it in disputes, we could increase the lru cache size of RuntimeInfo
to 6 and just query the current SessionInfo
from the cache on each active leaf update. This way we would keep the behavior of pro-actively caching sessions, to boost reliability even more (at the cost of some constant overhead).