libtracker-sparql-backend: Fix connection singleton mutex issue
libtracker-sparql-backend: Fix connection singleton mutex issue

Since moving from GStaticMutex to GMutex (due to deprecations in GLib), there
has been an issue noticed with the way the mutex is created. Before, the
GStaticMutex was created in the first instance from any API call and used
there on after. This meant the chance of it not being initialised when we used
it was almost 0.

Now with GMutex, because we've initialised it differently (in the class
constructor) with Mutex() this means that g_mutex_init(&_tmp0_) is the
generated source from that. Sadly, the first instance of g_mutex_lock() will
create the mutex for us if it is NULL or {0} anyway and this happens _BEFORE_
the g_mutex_init() call. So we were locking, initing and the unlocking. This
is the cause of the problem.

Now we don't initialise the mutex at all and let that initialise upon first
lock. Note, atomic operations in GLib should protect race conditions affecting
creation of the singleton here.

https://bugzilla.gnome.org/show_bug.cgi?id=697316

hoheinzollern/tracker,outofbits/tracker,outofbits/tracker,hoheinzollern/tracker,outofbits/tracker,hoheinzollern/tracker,outofbits/tracker,outofbits/tracker,hoheinzollern/tracker,hoheinzollern/tracker,outofbits/tracker,hoheinzollern/tracker,outofbits/tracker,hoheinzollern/tracker