daemon: Catch thumbnail files in large directory as well

When building the file attribute table info, use thumbnail paths in
$XDG_CACHE_DIR/thumbnails/large in addition to
$XDG_CACHE_DIR/thumbnails/normal.

Failing to do this would cause an application that creates large
thumbnails by default to never find any value for
G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
application to either think thumbnailing is still in progress, or
blindly requeue thumbnail operations in a loop.

Large thumbnails are generally preferred, so we now default to the path
of a large thumbnail (in case both are present).

Fixes: https://bugzilla.gnome.org/688685
GDaemonFileEnumerator: Only listen to messages one connection

There is no need to listen to messages on other connections than
the one we sent the request on. In fact, doing so is bad as it can cause
locking issues as per bug 708721.

https://bugzilla.gnome.org/show_bug.cgi?id=708744
GDaemonFileMonitor: Only recieve events on one dbus connection

There is no need to register for monitor evens on all dbus connections,
just the one we send the request on.

https://bugzilla.gnome.org/show_bug.cgi?id=708744
client: Remove unused code for dbus vfs filters

This code is not used anymore

https://bugzilla.gnome.org/show_bug.cgi?id=708744
GVfsDaemon: Don't deadlock on cliend disconnect

There was a deadlock that could happen on client disconnect in
peer_connection_closed(). If the cancelled job immediately called back into
job_finished_callback() we would deadlock on daemon->mutex.

So, make sure we cancel jobs without holding the lock, just like
handle_cancel() does.

https://bugzilla.gnome.org/show_bug.cgi?id=708816
GDaemonFileEnumerator: fix compilation warning

https://bugzilla.gnome.org/show_bug.cgi?id=591228
gdbus: fix compilation warnings

https://bugzilla.gnome.org/show_bug.cgi?id=591228#c21
daemon: Emit signal before returning dbus value

In gvfsjobopenforread.c, the dbus method returns a value in create_reply
which eventually results in a GVfsJobRead job to be sent to the backend.
This could happen before the "new-source" signal is emitted.  If this
happens, the job is not queued because the "new_job" signal would not
have been connected to a job source yet.  The read then hangs because
the GVfsJobRead is lost.

This is hit often when performing large smb transfers (see
https://bugzilla.gnome.org/show_bug.cgi?id=697782 and
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923).
It can be reproduced by putting a small sleep before the
g_signal_emit_by_name call.

Fix this by emitting the "new-source" signal *before* the dbus method
value is returned.  This ensures that the "new_job" signal is set up
before any further jobs are sent.

Note that the same problem and solution applies for
gvfsjobopenforwrite.c.
fuse: Fix seek offset calculation

Since fh->pos is already incremented by n_bytes_skipped, check if
offset == fh->pos.

This error was hidden by the fact that the operation is retried when
-EIO is returned.  When it was retried, the stream was already in the
correct position and so no seek operation was required.
fuse: Enforce sync_read

When running multithreaded, fuse can issue readahead requests out of
order which can cause subsequent reads to fail with ENOTSUPP (if seeking
backward is not supported on the stream).

Force readahead to occur in order to prevent this problem.
fuse: Make file nonseekable if it actually is

Instead of failing in read() with ENOTSUPP after the lseek on a
nonseekable stream succeeds, make the lseek fail with ESPIPE, as it
should.  This is important for applications which test the return value
of lseek to determine if the file descriptor is seekable.
client: Don't user g_source_remove() on non-default main context

We created a GSource, attached it to a non-default main context and
then removed it via g_source_remove, which removed the source with the
same id on the main context, which typically was the X fd, causing
everything to stop working!

Non-default main contexts must use g_source_destroy()

https://bugzilla.gnome.org/show_bug.cgi?id=708744
sftp: Allow seek past end of file

also, don't query for the file size unless required for SEEK_END

https://bugzilla.gnome.org/show_bug.cgi?id=709432
cdda: Allow seek past end of file

https://bugzilla.gnome.org/show_bug.cgi?id=709432
gphoto2: Allow seek past end of file

https://bugzilla.gnome.org/show_bug.cgi?id=709432
fuse: Use the big_writes option to speed up writes

Without the big_writes option, fuse uses a block size of 4096 bytes
which results in poor write performance.  So use the big_writes option
to write blocks up to 64KiB in size.

https://bugzilla.gnome.org/show_bug.cgi?id=652540
http: Set error to NULL to possibly prevent crash on close

https://bugzilla.gnome.org/show_bug.cgi?id=710678
sftp: Return the correct error code on failed symlink creation

If the symlink path already exists, return the correct error code of
G_IO_ERROR_EXISTS.

https://bugzilla.gnome.org/show_bug.cgi?id=710935
client: Fix SIGSEGV in fallback copy

If the daemon is killed during the fallback copy, it is possible that
proxy is NULL which causes a segfault when unrefing it.  Use
g_clear_object() instead.

https://bugzilla.gnome.org/show_bug.cgi?id=711454
programs: Escape string properly

Use an unsigned char to avoid implementation-defined behavior of a right
shift.
Shift by 4 rather than 8 to get the second half of a byte.

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