This temporarily disables logs capture for the time of restoration.

This function is invoked when sqlite3changeset_apply encounters issue when applying change. I highly recommend reviewers to read detailed explanation here, but I will shortly explain what is going on here and why I decided to implement conflict handler like this.

The second argument to conflict handler is the conflict reason and return value from handler dictates how conflicting change is treated. In our case we can have the following conflict reasons:

• SQLITE_CHANGESET_NOTFOUND - when deleting a row that doesn't exist or when updating the row that doesn't exists. Both of these would happen if we miss a log that inserts relevant row.
• SQLITE_CHANGESET_CONSTRAINT - when any operation would violate database constraints. This could happen if we miss a log that deletes a row in a table with unique key and then try to insert another row with the same value in this field.
• SQLITE_CHANGESET_CONFLICT - this happens if we try to insert data but row with the same primary key already exists. This can happen if we miss deletion log. Fortunately we have an easy way to recover from this one. By returning SQLITE_CHANGESET_REPLACE we will make sqlite3shangeset_apply delete previous row and reattempt insertion.

In summary all conflicts we might encounter are due to the fact that we missed some logs. Apart from the last one we don't have an easy automatic way to recover from them. Theoretically we could recover from SQLITE_CHANGESET_NOTFOUND during update by inspecting update statement and constructing insert statement from it. However it would complicate the code significantly. That said I implemented this stack to ensure that no logs are missed in the first place, so in conflict handler I just inspect conflict content, log it and either solve if is the easy case with insert or return SQLITE_CHANGESET_OMIT which makes sqlite3changeset_apply ignore the change.