libtracker-sparql: Move FTS initialization to an earlier stage
With SQLite >= 3.44.x, the check_integrity pragma may involve existing
virtual tables and their xIntegrity vmethod. This includes FTS5 tables,
so we need to set up the FTS5 tokenizer at an earlier stage, so that
possible integrity checks happening on startup have everything set up.
libtracker-sparql: Decouple FTS initialization from ontologies
Since we just need the FTS properties for fts:offsets being called
at runtime, we can pass the TrackerDataManager (that we know early
in startup) and let it figure out the FTS properties from there
when it's actually needed.
This is just the refactor to make that possible, there's no
functional changes in this commit.
Currently this is handled through a TrackerDBManager signal that
gets emitted too soon for the TrackerDataManager to connect any
high-level behavior to it.
Handle this via a getter, so that the data manager can perform its
own checks at the desired place in its own initialization paths.
The two branches checking loading an ontology file after checking
it is brand new or had a changed nrl:lastModified are pretty much
identical. Refactor the code so that it is the same code handling
both situations.
This code path is vestigial code from pre-3.0, at the time the
Graph table was added. All 3.x versions have this table, so there's
no need to handle its non-existence.
Test some corner cases here:
- Locale changes triggering FTS/index rebuilds
- Startup after an unclean shutdown
- Updating from various older 3.x database versions
