Also create new TrackerDataProvider when creating crawler to avoid test
failures

These are needed for many of the unit tests.

This reverts commit 65951061.

It's now a property of a TrackerDataProvider

Now TrackerMonitor is a part-implementation for that interface managed in
TrackerFileDataProvider

SPARQL update strings can be very long if the entire text of a document
is being stored. Dumping these huge strings to the log eats up disk
space and makes them harder to follow.

However, often, the occurence of such an error indicates a broken
extractor. In those cases, knowing part of the SPARQL can help in
identifying the file that triggered the error.

Usually the "nie:plainTextContent" property is the last one in the
string, so we truncate the error messages at the first occurance of
this property to achieve the best of both worlds.

https://bugzilla.gnome.org/show_bug.cgi?id=735406

https://bugzilla.gnome.org/show_bug.cgi?id=742391

If Tracker can't resolve special dirs like &DOCUMENTS to real path
names, it now gives a warning like this:

    (tracker-miner-fs:7207): Tracker-WARNING **: Unable to get XDG user
    directory path for special directory &DOCUMENTS. Ignoring this
    location.

Previously (since commit 5f06c134) the
user would see this rather more scary output:

    (tracker-miner-fs:6046): GLib-GIO-CRITICAL **: g_file_new_for_path:
    assertion 'path != NULL' failed

    (tracker-miner-fs:6046): GLib-GIO-CRITICAL **: g_file_equal: assertion
    'G_IS_FILE (file1)' failed

    (tracker-miner-fs:6046): GLib-GObject-CRITICAL **: g_object_unref:
    assertion 'G_IS_OBJECT (object)' failed

This situation is rare (you need to manually change or break
XDG_CONFIG_HOME to really see it) but it's always nice to avoid showing
critical errors!

The config file format changed in commit
2b53cd5d.

Firstly, allow specifying multiple --content options, and allow
specifying --content-non-recursive if you really want as well.

Also, don't generate an XDG user directories config. It seems a bit
weird to be doing this and setting each directory to the same location.

https://bugzilla.gnome.org/show_bug.cgi?id=742035

media_art_process is not set when running tracker-extract-info tests

https://bugzilla.gnome.org/show_bug.cgi?id=742035

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.

https://bugzilla.gnome.org/show_bug.cgi?id=739234

https://bugzilla.gnome.org/show_bug.cgi?id=663687

This test adds data that would normally be added by the FS miner.
In order for the resource to be correctly deleted when the file is
removed, it must set nie:isStoredAs correctly.

This makes the following error less likely, and clearer when it does
occur:

    (tracker-miner-fs:28886): Tracker-WARNING **: Could not open directory 'file:///home/sam/tracker-tests/writeback': Not a directory

Tests shouldn't break just because --enable-guarantee-metadata is not
specified at configure time. This feature is off by default so we
shouldn't depend on it. See GB#733536.

If extraction with GstDiscoverer fails due to lack of a plugin, we can
display exactly what plugin was missing rather than just giving a
generic error. This makes it a bit easier to fix the problem.

Since commit 41e6ab84, the contents of
directories listed in 'index-single-directories' is be ignored. The
directory itself appears in the store but the contents do not.

The intention of passing max_depth=1 if TRACKER_DIRECTORY_FLAG_RECURSE
is false must be to prevent unnecessarily processing any subdirectory
nodes that are hanging around in the TrackerFileSystem. However, the
documentation of g_node_traverse says:

    "If depth is 1, only the root is visited. If depth is 2, the root
    and its children are visited. And so on."

Thus, we must pass max_depth+1 to the tracker_file_system_traverse()
function so that the files in the directory are processed as well as
the directory itself.

See also: 243c97fa which introduced the
'max_depth' parameter as a way of reducing the number of GFile objects
in memory at the same time during crawling.

Rather than running all the tests in one environment, create a new
environment for each test. Although it's slower this way, it's just too
hard to debug test failures when the tests can interfere with each
other.

I also made them all use the same 'minertest' base class.

Instead of using `tracker daemon --kill=miners` to stop the miners, use
the Python 'subprocess' module. This ensures only the correct miner
process gets killed if more than one is running. (I also found that
`tracker daemon --kill-miners` was hanging my system, which was the real
motivation for fixing this, but I have no idea why that happened).

If a process fails to terminate after we sent it TERM, it now gets sent
KILL. Previously the test would wait forever.

All 3xx tests should now pass except 2 of the 310-fts-indexing tests.

This allows detecting when a file move has been done, and probably other
useful things too.