[tracker] libtracker-data: Drop unconditional locks around wal checkpoints

[Carlos Garnacho <carlosg src gnome org>]

commit 69c3cf70c9ab94727d7e045576a92853c30e58c3
Author: Carlos Garnacho <carlosg gnome org>
Date:   Fri Mar 1 14:22:42 2019 +0100

    libtracker-data: Drop unconditional locks around wal checkpoints
    
    This can happen from 2 different places:
    1) Idly on a thread. In this case it uses a dedicated interface, so
       there's no need to lock it. We use a passive checkpoint, so it
       will also bail out if there are other readers or writers.
    2) Immediately on pressure. This will happen during database updates
       (eg. while stepping on a prepared statement). This case may happen
       from within other places we lock the interface
       (eg. tracker_db_interface_execute_vquery). This path will actually
       lead to deadlocks, as we try to lock the mutex while already holding
       it. And anyway this will happen on an interface dedicated to updates
       used from a single thread.
    
    Just drop the lock/unlock calls here. We don't need them. Fixes deadlocks
    seen on case number 2.

 src/libtracker-data/tracker-db-interface-sqlite.c | 2 --
 1 file changed, 2 deletions(-)
---
diff --git a/src/libtracker-data/tracker-db-interface-sqlite.c 
b/src/libtracker-data/tracker-db-interface-sqlite.c
index 0ff72dcae..16d201d10 100644
--- a/src/libtracker-data/tracker-db-interface-sqlite.c
+++ b/src/libtracker-data/tracker-db-interface-sqlite.c
@@ -1963,11 +1963,9 @@ tracker_db_interface_sqlite_wal_checkpoint (TrackerDBInterface  *interface,
 {
        int return_val;
 
-       tracker_db_interface_lock (interface);
        return_val = sqlite3_wal_checkpoint_v2 (interface->db, NULL,
                                                blocking ? SQLITE_CHECKPOINT_FULL : SQLITE_CHECKPOINT_PASSIVE,
                                                NULL, NULL);
-       tracker_db_interface_unlock (interface);
 
        if (return_val != SQLITE_OK) {
                g_set_error (error,