Implement op caching in ODSP driver

[vladsud]

There is feedback from users that snapshot caching in ODSP driver results in non-optimal UX behavior:

1. User opens a file and types a bunch of text
2. User closes tab
3. User opens tab

Result:
Old snapshot (cached) is rendered, without changes typed by user above.
After some time, user's edits show up.

Work mentioned in #4767 would partially solve this problem by reducing time to show latest edits. But it is still bound by network request and time to process ops.

We should (as part of this change)

1. Cache ops in ODSP driver (in chunks, let's say 100 ops a piece) using IPersistedCache.
2. On fetching snapshot, fetch all the ops from the cache and add them to the list of ops available for future use (we can add it to this.ops, but this is used only once, and have certain assumptions around usage, so if we are too late with merging ops to it, it will not work).
3. Start looking if we could reliably process ops before we render, i.e. if ops are returned as part of above mentioned issue soon to runtime, is there some mechanism (opt-in or not) that would allow to process them before container is returned to client? I'd split this item, as it's not clear if this can be done without affect other metrics (time to render), and it's sort of independent from everything else

[christiango]

@vladsud, I agree about the third item being a separate item. I'll log one

[vladsud]

I've started working on it...

[vladsud]

#5288 shows the amount of traffic we are creating (op sizes in typical complex doc).
#5211 looks deeper into metrics around how fast we can catch up and opportunities for faster catch up.

At the current moment, given all the data, #5211 is more important to address than this item, as it will improve (if done right) catch up process 3x (bigger payloads, parallel requests). It is also simpler to solve than this item. So I'm prioritizing it over caching, but intend to do both in March.

Feedback is welcome!