core: Fix incompatibility introduced by SQLite 3.45.3

Closes #435

See merge request !665

For the umpteenth time, SQLite introduced behavioral changes that
we need to adapt to. This time, version 3.45.3 "fixed" at
https://github.com/sqlite/sqlite/commit/74851f66811854c772a9b2d0a13f1e9e82b69c25
their SQLITE_ALLOW_ROWID_IN_VIEW build-time option which controls the
behavior of views having an implicit ROWID column vs not.

This broke our view used to proxy data to the content-less FTS5
table, since the SELECT query it translates to used a naked reference to
ROWID that is now deemed "ambiguous" by SQLite engine, this results
in the following errors:

Tracker:ERROR:../tests/core/tracker-ontology-test.c:231:test_query: assertion failed (error == NULL): ambiguous column name: ROWID (tracker-db-interface-error-quark, 0)

We are actually referencing data inside the SELECT query, so fix this
ambiguity by stating clearly the table/column that we are referring to
within the SELECT query clause. This is backwards compatible with older
versions of SQLite.

Closes: GNOME/tracker#435

Fix DELETE/WHERE maybe altering its own resultset

See merge request !664

The changes in the delete clause should not alter the results that the where
clause goes through. Add a test ensuring that.

Currently, we perform the insert/delete operations while iterating
a cursor dealing with the where clause. Performing updates while
performing select queries and iterating through cursors is usually
not an issue, but that is only true (with WAL) if this is performed
through different interfaces, so the readers can interact with the
unmodified database while updates are accumulated in the write-ahead
log. More information at https://www.sqlite.org/isolation.html.

But here, we are dealing with a cursor created from the update thread,
inside the same lock and seeing the same data than the latest update.

So, if a delete{}insert{}where{} query happens to be modifying data
that alter the results of the where{} clause, we might be getting the
cursor silently updated underneath, thus either missing data that
originally matched the where{} clause, or overreaching with brand
new data that happens to match the where{} clause.

As per the specs, the ex...

Most regularly, we can do (and prefer) small buffers. This is not universally
true, so add this mechanism to ensure that operations will accumulate without
database changes until fully thawed, at which point flush will work again.

Currently, the update machinery works on fairly small fixed buffers,
and is optimized for the buffer never growing beyond those limits.
Nominally, pointers to elements of a fixed size GArray are used as
keys in a hashtable, so any realloc in the array due to the buffer
overgrowing would render this hashtable data invalid.

Handle indefinite growth, and make this array of elements an array
of arrays of elements. This way we keep low sizes by default, allow
growing without invalidating previously existing pointers (by adding
new small sized buffer chunks), and during regular operation (i.e.
with the buffers not overgrowing) this just takes a couple more memory
allocations.

Fix stalls in error handling of DBus updates

Closes tracker-miners#328

See merge request !663

Write SPARQL queries asynchronously, in all of our update(_async)
and batch operations. This means we wait for both the DBus message
and the FD write responses to consider the operation finished,
like we already do for deserialization.

Closes: tracker-miners#328

The input stream obtained from a DBus request is leaked after use.

libtracker-sparql: Document handling of corrupted databases

See merge request !662

We need more modern gi-docgen than what Fedora provides to
handle linking to specific error enum values correctly.

Add blurbs aroung the tracker_sparql_connection_new(_async) and
TRACKER_SPARQL_ERROR_CORRUPT docs.

Extend coverage

See merge request !661

Ensure that its values match the expectations.

Make it unnecessary for subclasses to override the property, by calling the
get_n_columns() virtual method. This also makes the property getter consistent
with the public method for all cursor implementations.

Nothing uses the TrackerDBStatement property getters. Make all its properties
writable only.

Nothing uses the TrackerData::manager property getter, we can
make this property fully write-only.

This flags variable is unused.

Add some more tests for its behavior.

Add some more tests to cover datetime function behavior.

Test some more corners of the builtin functions.

Rename some tests for clarity about what functions do they test, and add
more tests around the tracker: namespace set of string functions.

We cannot have a SQLITE_TEXT parameter with a NULL string.

The g_filename_display_basename() function cannot return NULL unless
other precondition checks fail.

And use it for all precondition checks in the available SQLite
functions.

According to the spec, this should return the empty string.