I don't want to create new file for each log. I think we should rather accumulate X logs in a single file and the create new file with new log id. This constant is X. We can set it to arbitrary number.

This method handles the case where we were storing logs to file identified by certain logID but the app was closed/killed before logsCount exceeded threshold and/or before it could update logID in the database. In such case we have to increment logID and start new file.

This code is not needed anymore.

I decided to couple database connection and logs session ina single object to avoid the possibility that connection is closed before the session is deleted. According to SQLite docs deleting a session (or doing anything with it) if the connection it was created for was closed results in undefined behaviour (which possibly means segmentation fault).

I plan to run this call in separate thread as a part of ENG-6226. However I will first do some performance tests to measure how much time does it take on average to capture log and see how important it actually is to introduce additional thread.

Session object is not "zeroed" after capturing the log (see here name) - reading from the same session multiple times will give us all captured changes from the beginning of session instantiation. Therefore we have to delete and recreate session after capturing logs.

It was actually my initial idea but I was afraid that reviewers will find it too verbose.

shouldn't we add the same flags to run_emscripten.sh? I know it won't be used but just to make sure we use the same engine configs

Wondering if using std::ofstream::write() without std::string and operator<< isn't better when it comes to binary data, also maybe it's faster?
I remember having some issues in the past with it doing something similar in C++, especially with null characters but since you test it it's probably okay.

is it possible to have changesetPtr not null but changesetSize == 0? In that case shouldn't we call sqlite3_free(changesetPtr);?

They are added in the diff that introduces restore from logs functionality.