This allows us to be smarter about when to look up the IRI on the database.
If a file is created and being slowly written to (eg. downloads),
::file-created will be emitted for the file eventually, but the updates
will keep the file instance alive on the TrackerFileSystem.

In this case we attempted to be smart and avoid querying needlessly the
database for the IRI, which resulted on a mistakenly NULL IRI, and on
an attempt to "create" the item again, even though it existed. This
resulted in "UNIQUE constraint" errors.

One thing we can do is "invalidating" the IRI, so the next time we
call tracker_file_notifier_get_file_iri() on it, a query is forced only
in these situations, this will make later updates happy with the right
IRI.

If the updates are too slow, and the file happens to be flushed out
of the TrackerFileSystem (all non-directory files do), the next update
would trigger again its insertion, and the IRI would be queried again,
so we're safe in that regard.

https://bugzilla.redhat.com/show_bug.cgi?id=1192224