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.

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, 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 execution order is executing the where{}, obtaining
resultset, then apply delete+insert clauses on each result. We cannot
let these updates happen while iterating the resultset, so freeze/thaw
the flush mechanism to ensure that these update operations are accumulated
without effects on the database. After all the results are iterated, the
accumulated operations will be flushed at once.

Related: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/327

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

Fix DELETE/WHERE maybe altering its own resultset

See merge request https://gitlab.gnome.org/GNOME/tracker/-/merge_requests/664

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: https://gitlab.gnome.org/GNOME/tracker/-/issues/435

core: Fix incompatibility introduced by SQLite 3.45.3

Closes #435

See merge request https://gitlab.gnome.org/GNOME/tracker/-/merge_requests/665