As a previous, incorrect attempt to fix RHBZ#576879 we tried to
prevent the daemon from sending an error reply if the daemon had
cancelled the transfer.  This is wrong: the daemon should send an
error reply in these cases.

A simple test case is this:

  guestfish -N fs -m /dev/sda1 upload big-file /

(This fails because the target "/" is a directory, not a file.)
Prior to this commit, libguestfs would hang instead of printing an
error.  With this commit, libguestfs prints an error.

What is happening is:

  (1) Library is uploading
  a file                          (2) In the middle of the long
                                  upload, daemon detects an error.
                                  Daemon cancels.
  (3) Library detects cancel,
  sends cancel chunk, then waits
  for the error reply from the
  daemon.                         (4) Daemon is supposed to send
                                  an error reply message.

Because step (4) wasn't happening, uploads that failed like this would
hang in the library (waiting for the error message, while the daemon
was waiting for the next request).

This also adds a regression test.

This temporarily breaks the "both ends cancel" case (RHBZ#576879c5).
Therefore the test for that is disabled, and this is fixed in the next
patch in the series.

This partially reverts commit dc706a639eec16084c0618baf7bfde00c6565f63.

This file is already hard-linked into the current directory, so
the relative path is not required.

During a FileIn command (eg. upload, tar-in) if both sides
experience errors, then both sides could send cancel messages,
the result being lost synchronization.

The reason for the lost synch was because the daemon was ignoring
this case and sending an error message back which the library side
(which had cancelled) was not expecting.

Fix this by checking in the daemon for the case where the library
also cancels during daemon cancellation, and not sending an error
messages.

This also includes an enhanced regression test which checks for this
case.

This extends the original fix in
commit 5922d7084d6b43f0a1a15b664c7082dfeaf584d0.

More details can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=576879#c5

Modify the generator so that it can correctly handle early
cancellation for Pathname|Device|.. parameters.  This fixes
the upload command, but consequently we need to fix the
parameters for tar_in and t?z_in commands.  This should also
mean that 'win:' can now be used as the second argument of
tar_in and t?z_in commands in guestfish, whereas previously
this wouldn't have worked.

Adds a regression test for the original problem.

The RPC stubs already prefix the command name to error messages.
The daemon doesn't have to do this.  As a (small) benefit this also
makes the daemon slightly smaller.

Code in the daemon such as:

  if (argv[0] == NULL) {
    reply_with_error ("passed an empty list");
    return NULL;
  }

now results in error messages like this:

  ><fs> command ""
  libguestfs: error: command: passed an empty list

(whereas previously you would have seen ..command: command:..)

* daemon/command.c (do_sh_lines, do_sh): Do not shadow global "command".

Also, ...
* src/generator.ml: Add DeviceList type, and propagate that change
out to all calling/interface code.

Nearly every file-related function in daemons/*.c is affected:
Remove this pair of statements from each affected do_* function:
-  NEED_ROOT (return -1);
-  ABS_PATH (dir, return -1);
and change the type of the corresponding parameter to "const char *".
* src/generator.ml: Emit NEED_ROOT just once, even when there are two or
more Pathname args.

run this command:
  git grep -l -w NEED_ROOT|xargs perl -pi -e \
    's/(NEED_ROOT) \((.*?)\)/$1 (return $2)/'