SSS: Enter "recovering" mode if the app has been offline for "a while"

[erikjohnston]

c.f. element-hq/element-x-ios#3223 (comment), cc. @Hywan

This helps ensure that the next sliding sync request is responded to fast by the server. If we use a pos token from a long time ago with the full range, the server will need to respond with potentially lots and lots of updates, which might take a while

It'd be good to reduce the range back down to [0-19] after some time of inactivity (but not reset the connection, like we do when we see a connection error/timeout). This will then allow the server to (hopefully) respond quickly to the first request and for the client to fetch the rest of the updates in when the list grows. I don't think it really matters too much if we reduce to [0,19] relatively quickly, so I'd probably suggest a 1hr timer would be a good first try.

[Hywan]

Thanks for creating the issue.

[ara4n]

why do we need to do this, if the server is forceably resetting the client when the backlog gets too big (or too much time goes by)? it feels like the server should be the on telling the client when to recover (by resetting it) rather than the client having to guess what's going on in the server.?

[erikjohnston]

@ara4n resetting the connection adds extra load to the server, clients and bandwidth as we resync all the old rooms (including state etc). Having the client reduce the range allows us to have a fast sync without losing having to resync everything.

[erikjohnston]

(We should and will still reset server side if there are too many updates though)

[ara4n]

ah right. so another way of putting it: "if a backlog has built up, it's better to work through it incrementally by repaginating over the roomlist rather than having a long delay to catch up with the full range (if the SSS session hasn't reset)"