miner-fs: Fix tracking file move

[tracker] Fix tracking file move

Identified by MinerCrawlTest::test_07_move_from_monitored_to_monitored
(300-miner-basic-ops.py)

In item_move() it fails to get source_iri, does not check it's validity and
uses it in the DELETE expression of the SPARQL query constructed there.

Broken since d836f00 (libtracker-miner: Store iri transiently as GFile
qdata) - tracker_file_notifier_get_file_iri() is added 'force' argument
and (wrapped with lookup_file_urn) passed force=FALSE from item_move().
This call then fails for regular files because only directories are
cached once crawling has completed as stated in the comment in
finish_current_directory() in libtracker-miner/tracker-file-notifier.c.

https://bugzilla.gnome.org/show_bug.cgi?id=678986
Fix "functional-tests: Rework 400-extractor.py test"

This fixes 7685f7b (functional-tests: Rework 400-extractor.py test)
extract: Add application/msword back to msoffice rules

[tracker] Fix indexing MS Word documents

Identified by functional-tests/400-extractor.py, case office-doc.

This ugly mime type has been misidentified as useless in scope of
GB#733317 and removed with f04b2de (tracker-extract: remove
application/vnd.ms-* catchall from msoffice). Still it is the mime type
returned by libmagic/GIO - the result is contents of (some?) doc files
are never extracted.

https://bugzilla.gnome.org/show_bug.cgi?id=733317
miner-fs: Remove unused argument is_new

Just a minor polishing prior to the next change.

https://bugzilla.gnome.org/show_bug.cgi?id=678986
miner-fs: Fix handling files moved soon after creating

[tracker] Fix handling files moved soon after creating

Noticed this when executing functional tests for write-back:

(tracker-miner-fs:21288): Tracker-CRITICAL **: Could not execute sparql:
 Subject `(null)' is not in domain `nfo:FileDataObject' of property
 `nfo:fileName'

There are more ways to get into this. One example:

copy ("file.txt", ".temp_XYZ.file.txt")
 - received G_FILE_MONITOR_EVENT_CREATED (".temp.file.txt")
 - received G_FILE_MONITOR_EVENT_CHANGED (".temp.file.txt")
 - received G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT (".temp.file.txt")
modify (".temp_XYZ.file.txt")
 - received G_FILE_MONITOR_EVENT_CHANGED (".temp.file.txt")
 - received G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT (".temp.file.txt")
mv (".temp_XYZ.file.txt", "file.txt")
 - received G_FILE_MONITOR_EVENT_MOVED (".temp.file.txt", "file.txt")
 - emitted  ITEM_MOVED (".temp.file.txt", "file.txt")

It was already handled in item_move() in past, but removed with eef0e7f
(libtracker-miner: Remove useless code) after previously misidentified
as useless in scope of ee58e67 (libtracker-miner: Add compat layer for
tracker_miner_fs_directory_*)

The comment from ee58e67 """FIXME: This situation shouldn't happen from
a TrackerFileNotifier event""" simply cannot be satisfied: no way to get
".temp.file.txt" indexed before ITEM_MOVED is processed - the file
disappears too fast.

This commit extends TrackerMonitor with one more case which can be
handled there though.

https://bugzilla.gnome.org/show_bug.cgi?id=678986
functional-tests: Fix 501-writeback-details
Use g_unix_signal_add() for signal handlers

[tracker] Do not hang on exit randomly

Identified by functional-tests/17-ontology-changes timeouting randomly.

Documentation for g_unix_signal_source_new() explains why it is not safe
to call g_main_loop_quit() from a regular UNIX signal handler.

Intentionally removed the (main_loop != NULL) tests - this cannot happen.