When a connection is proxied through a TrackerEndpointDBus, there are
possibly 2 levels of TrackerNotifiers, one being used in the service
itself to trigger the DBus signal, and another on any listening client
handling those notifications.

However, both of these are doing an additional query to fetch the URN
for each of the notified elements. Since we only pass ROWIDs in the
DBus signal to make the signal data as compact as possible, we can
avoid this query on the service side. Any client listening to
notifications will perform its own URN queries anyway.

So avoid this piece of pointless busywork in the service side, and
special case that the internal notifiers used by endpoints should not
perform the query for URN data.

This does not make anything noticeably faster (perhaps endpoint signal
emission is a bit more snappy now, if anything) as all querying and
cursor handling happens lazily in a separate thread fairly detached
from the rest of the machinery. However it's still less CPU cycles
used overall.

If a database/ontology has no fulltext-indexed properties, we do not
create a corresponding FTS table. Likewise, parser/locale updates
should not attempt to update it, or we will get a "SQL logic error"
poking non-existing tables.

Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2278

This is not quite correct, but it is the most straightforward way to sort
of handle situations in our own Nepomuk ontology that superproperties have
different rdfs:range than their subproperties.

For these cases, handle the conversion of the value. Since the worst case
(and the one we happen to exercise) is about converting resource ROWIDs to
strings, handle this specific situation.

This helps in serialization and deserialization of this data, since the
ROWIDs were not something that could be replicated in other databases
without mismatches (e.g. the resource having a different ROWID in the
new database importing the data) or worse (e.g. cardinality or other
constraints broken).

The order of the returned resultset was implicit and up to SQLite, but
the order for this test started changing starting with SQLite 3.39.0.
Make the order explicit, so that SQLite implementation details don't
leak up here.

Closes: https://gitlab.gnome.org/GNOME/tracker/-/issues/370

Fix occasional build failures such as this one:
https://gitlab.gnome.org/GNOME/tracker/-/jobs/2101449

And GType boilerplate generation. This enum is entirely unused
in the tracker code and is thus unneeded.

We are just looking at the default graph when initializing nrl:modified
after opening an existing database. Since the default graph possibly
only contains part of the data, we are possibly/likely missing the latest
sequence number if used on other graphs.

Check all graphs here relying on our virtual tracker_triples table, so
we are ensured to get the actual latest/greatest nrl:modified sequence
that was previously used from the union of all graphs. This ensures us
to get always a fresh sequence number for newly inserted data.

Backports for 3.3

See merge request GNOME/tracker!521