fuse, glusterfsd: mount logic fixes

Commit 7d0397c2 introduced two issues:

 i) broke the libfuse derived mount logic (details below)
ii) in case of a daemonized glusterfs client is ran as daemon, parent
    process can return earlier than the mount is in place, which breaks
    agents that programmatically do a gluster mount via a direct call to
    glusterfs (ie. not via mount(8)).

This patch fixes these issues by a refactor that merges the approaches
sported by commits

  7d0397c2 fuse: allow requests during mount (needed for SELinux labels)
  c5d781e0 upon daemonizing, wait on mtab update to terminate in parent

Original daemonized libfuse event flow is as follows:

  try:
    fd = open("/dev/fuse")
    mount("-oopts,fd=%s" % fd ...)
    mount(8) -f    # manipulate mtab
  except:
    sp = socketpair()
    env _FUSE_COMMFD=sp fusermount -oopts
    fd = receive_fd(sp)

  where fusermount(1) does:
    fd = open("/dev/fuse")
    mount("-oopts,fd=%d" % fd ...)
    sp = atoi(getenv("_FUSE_COMMFD"))
    send_fd(sp, fd)

  daemonize(
    # in child
    fuse_loop(fd)
  )
  # in parent
  exit()

As of 013850c9 (instead of adopting FUSE's 47e61004¹), we went for async
mtab manipulation, and as of c5d781e0, still wanted keep that in sync
with termination of daemon parent, so we changed it to:

  try:
    fd = open("/dev/fuse")
    mount("-oopts,fd=%s" % fd ...)
    pid = fork(
      # in child
      mount(8) -f
    )
  except:
    sp = socketpair()
    env _FUSE_COMMFD=sp fusermount -oopts
    fd = receive_fd(sp)

  daemonize(
    fuse_loop(fd)
  )
  waitpid(pid)
  exit()

(Note the new approch came only to direct [privileged] mount, so fusermount
based mounting was already partially broken.)

As of 7d0397c2, with the purpose of facilitating async mount, the event flow
was practically reduced to:

  fd = open("/dev/fuse")
  fork(
    mount("-oopts,fd=%s" % fd ...)
    fork(
      mount(8) -n
    )
  )

  daemonize(
    fuse_loop(fd)
  )
  exit()

Thus fusermount based mounting become defunct; however, the dead
code was still kept around. So, we should either drop it or fix
it. Also, the mtab manipulator is forked into yet another child
with no purpose, while syncing with it in daemon parent is broken.
mount(2) is neither synced with parent.

Now we are coming to the following scheme:

  fd = open("/dev/fuse")
  pid = fork(
    try:
      mount("-oopts,fd=%s" % fd ...)
      mount(8) -n
    except:
      env _FUSE_DEVFD=fd fusermount -oopts
  )

  where fusermount(1) does:
    fd = getenv("_FUSE_DEVFD")
    mount("-oopts,fd=%s" % fd ...)

  daemonize(
    fuse_loop(fd)
  )
  waitpid(pid)
  exit()

Nb.:

- We can't help losing compatibility with upstream fusermount,
  as it sends back the fd only when mount(2) is completed,
  thus defeating the async mount approach. The
  'getenv("_FUSE_DEVFD")' mechanism is specfic to glusterfs'
  fusermount (at the moment -- sure we can talk about it with
  upstream)

- fusermount opens /dev/fuse at same privilege level as of
  original process², so we can bravely go on with doing the open
  unconditionally in original process

- Original mounting code actually tries to mount through
  fusermount _twice_: if first attempt fails, then, assuming
  subtype support is missing in kernel, it tries again subtype
  stripped. However, this is redundant, as fusermount internally
  also performs the subtype check³. Therefore we simplified the
  logic to have just a single fusermount call.

- we revert the changes to mount.glusterfs as of 7d0397c2, as
  now there is no issue with glusterfs to work around in that scope

¹ http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=blobdiff;f=ChangeLog;h=47e61004;hb=4c3d9b19;hpb=e61b775a
² http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=blob;f=util/fusermount.c;h=b2e87d95#l1023
³ http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=blob;f=util/fusermount.c;h=b2e87d95#l839

Change-Id: I0c4ab70e0c5ad7b27337228749b266bcd0ba941d
BUG: 811217
Signed-off-by: Csaba Henk <csaba@redhat.com>
Reviewed-on: http://review.gluster.com/3428
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>