commit 28142bdb makes
trackers file monitoring code fall back to GLib file monitors,
if fanotify doesn't work.

Unfortunately, fanotify_mark failures aren't propagated up,
so the fall back code doesn't get triggered in some cases.

This commit adds the plumbing to make the fall back code get
propagated.

Closes #217

libtracker-miner: Properly detect fanotify failures

Closes #217

See merge request GNOME/tracker-miners!390

The field containing IPTC metadata can come either as TIFF_LONG (32-bit
ints, endianness dependent), or TIFF_UNDEFINED (a byte string). We currently
handle everything as TIFF_LONG, which may cause memory corruptions if we
deal with a file where we must perform endianness swapping and receive
non-long-aligned data.

Ensure to handle only these 2 types as it is defined for the TIFFTAG_RICHTIFFIPTC
tag, and only perform byte swapping for non-byte data (i.e. TIFF_LONG).

This is more in line with what other (e.g. ImageMagick) do when dealing with
byte-swapping and IPTC data.

Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/364

tracker-extract: Check field type on IPTC data embedded in TIFFs

Closes tracker#364

See merge request GNOME/tracker-miners!391

There are some situations where the file monitors cannot distinguish between
a file being created where none existed before, or a file newly created
replacing a previously existing file.

Treat all create/update events the same WRT trimming the previously
existing nie:InformationElements, in order to ensure these updates that
pass as creates also result in the file being reindexed by the
metadata extractor. This only applies to files that would have metadata
extracted.

While at it, simplify the SPARQL and move the code so that it is not
scattered across the function.

tracker-miner-fs: Always delete graph nie:InformationElement on create/update

See merge request GNOME/tracker-miners!392

Currently, the code paths handling cancellation of a TrackerCrawler async
request attempt to still emit ::directory-finished and update stats. However
this causes invalid memory accesses on finalization paths, since the
TrackerFileNotifier has been already disposed at the time the async callback
is handled. This may result in crashes.

To fix this, avoid all TrackerFileNotifier manipulation in the cancellation
paths of the async callback, the callback is meant to execute and bail out
cleanly now in these situations. This makes it a responsibility of the
g_cancellable_cancel() caller to instruct the TrackerFileNotifier how to
proceed.

Other callers, like the paths handling unmount and deletion of the folder
being crawled, have also been updated to ensure TrackerFileNotifier
resumes operation correctly after those situations.

Fixes: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/223

libtracker-miner: Fix TrackerFileNotifier cancellation paths

Closes #223

See merge request GNOME/tracker-miners!394

Suppose this should have been dc:language but since to my knowledge
this has never worked, and the other audio/video extractor don't
use such a property, let's just remove this here.

Avoid non-existing nfo:language on libav extractor

See merge request GNOME/tracker-miners!397

Previously, a non-existent macro `handle_tag` got undefined here.

It was broken after 062e726b ("tracker-extract-oasis.c: Improve parsing
of .odt files").

.odg and .ods (only?) contain text:p tags. The mentioned commit changed
a `g_ascii_strncasecmp("text", ..., 4)` call to
`g_ascii_strcasecmp("text", ...)`, breaking the detection of text in
those files.

Currently, the GTimer used to log the time spent processing is used
in a broken manner. It is only started once when the miner is started,
and every later batch of processing (e.g. monitor events) just stops
the timer and prints the elapsed time, which simply extends the elapsed
time based on the fixed start time, and info logging about our elapsed
time are forever based on the moment the miner was started.

Since the places where the timer is started currently don't apply to
monitor events after the miner is running, ensure the timer is started
when events do arrive in a state of idleness.

This ensures our elapsed time always reports the time spent in processing
the batch of events, until the miner becomes idle again.

Files are not "notified" anymore anywhere, so this counter is always 0.

Confusingly, moved and deleted events don't change the stats at all,
generalize the processing counting so it also caters for changes
processed, besides files/folders being checked in the filesystem.

When a directory is renamed and a recursive renaming of the
nfo:FileDataObjects starts, we use very widely generic queries to
mirror all the data from the old nfo:FileDataObjects to the new
ones with the updated URIs.

This { ?s ?p ?o } query results in the triples virtual table being
queried in the most generic way possible, thus all values are
returned. This makes the updates that handle these recursive moves
dependent on the number of elements in the database.

The use of unrestricted queries is actually discouraged in Tracker
documentation [1], so avoid falling in our own foretold mistakes.
Since we do know the data we expect to exist in a nfo:FileDataObject
in both the tracker:FileSystem and content graphs, make the relevant
queries completely specific about the properties being moved from
the old nfo:FileDataObject to the new one.

The performance improvement when handling move events goes from
barely noticeable to massive, depending on the database size. For
~130K elements indexed, moving a directory containing 180 files
went down from 48-50s to ~2s.

[1] https://gnome.pages.gitlab.gnome.org/tracker/docs/developer/performance.html#avoid-queries-with-unrestricted-predicates

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

macOS: add pipe2 fallback

See merge request GNOME/tracker-miners!399

Since the queries did not specify the graph, there is some path
explosion due to the nie:dataSource being in multiple graphs,
so all combinations are shown and this is seen as duplicates in
the result lists.

Specify the graphs in all "tracker3 search" queries, so these
redundant object paths are trimmed, and we show unique results.
This also results in a speed up of the queries.

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

Tracker miner rss options to list and delete feeds

See merge request GNOME/tracker-miners!395

Improve logging of tracker-miner-fs-3 timing stats

See merge request GNOME/tracker-miners!398

tracker-miner-fs: Do not use unrestricted queries moving files

Closes #228

See merge request GNOME/tracker-miners!400

cli: Specify graphs in "tracker3 search" queries

Closes #229

See merge request GNOME/tracker-miners!401

Fix text extraction from .odg and .ods

See merge request GNOME/tracker-miners!396