Persistent event cache for timeline event

[alanpoon]

Fixes #164

1. Added Event_cache enable storage before client's synchronization
2. Added "use_cache" boolean for MatrixRequest::PaginateRoomTimeline
3. Added logic to decide whether to do timeline pagination based on event cache's length.

There is not need to manually add initial event to event cache because there is synchronization. EventCache::add_initial_events()

There is also no need to use Clientbuilder.sqlite_store_with_cache_path method as it just separates the cache path from the app data.

[kevinaboos]

Oh great! I wasn't sure if the SDK even supported this yet. However, I did just update to the most recent version of the SDK's main branch yesterday, so we should double-check that again to see what's changed.

Can you clarify exactly what level of support for event caching is implemented by this PR? I'm curious, because the kind of event caching behavior that I was describing in #164 is a full save and restore of all known events in all rooms, which is essentially equivalent to what Element Web/Desktop can do.
If we do add full support for saving/restoring the EventCache, then we'll also need to add a few other features before we merge this in:

• loading a room's timeline not at the very bottom by default, but at the point where it was last read.
• Implementing a "jump upwards to last read message" feature.
• Supporting timelines in "focused" mode (non-"live" mode), where you can paginate both backwards and forwards (which would now be required since we wouldn't be starting the timeline from the newest possible message.
• probably some other things too

But if this PR isn't doing that level of cache restore, then we can worry about it later when we do add full save/restore.

[alanpoon]

Oh great! I wasn't sure if the SDK even supported this yet. However, I did just update to the most recent version of the SDK's main branch yesterday, so we should double-check that again to see what's changed.

Can you clarify exactly what level of support for event caching is implemented by this PR? I'm curious, because the kind of event caching behavior that I was describing in #164 is a full save and restore of all known events in all rooms, which is essentially equivalent to what Element Web/Desktop can do. If we do add full support for saving/restoring the EventCache, then we'll also need to add a few other features before we merge this in:

• loading a room's timeline not at the very bottom by default, but at the point where it was last read.
• Implementing a "jump upwards to last read message" feature.
• Supporting timelines in "focused" mode (non-"live" mode), where you can paginate both backwards and forwards (which would now be required since we wouldn't be starting the timeline from the newest possible message.
• probably some other things too

But if this PR isn't doing that level of cache restore, then we can worry about it later when we do add full save/restore.

This screen shows the log of the Length of the event cache of the timeline. It is not 0. I am assuming that this proves that there is on-disk event caching and the timeline is displaying the events from the event cache. I have verified that "sqlite3 matrix-sdk-event-cache.sqlite3" followed by "SELECT * FROM events;" contains the cache.

Maybe I will continue this after #422 is being merged. I should also add to support no internet.