glusterd/snapshot: brick_start shouldn't be done from child thread

When creating a volume snapshot, the back-end operation 'taking a
lvm_snapshot and starting brick' for the each brick
are executed in parallel using synctask framework.

brick_start was releasing a big_lock with brick_connect and does a lock
again.
This will cause a deadlock in some race condition where main-thread waiting
for one of the synctask thread to finish and
synctask-thread waiting for the big_lock.

Solution is not to start_brick from from synctask

Change-Id: Iaaf0be3070fb71e63c2de8fc2938d2b77d40057d
BUG: 1100218
Signed-off-by: Vijaikumar M <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/7842
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
features/quota: Send the immediate parent with limit in quota statfs adjustment

Problem:
Assume the directory structure /quota_limit_dir/subdir and quota_limit_dir is
set with some limit. When quota-deem-statfs is enabled the output of
'df /quota_limit_dir' would display quota modified values wrt to
quota_limit_dir where as 'df /quota_limit_subdir/subdir' would display the
quota modified values wrt volume root (/).

This behaviour is not expected since, when mounted with subdirectory admin
doesn't want users to know information above the subdirectory mounted.

Solution:
Any subdirectory within a quota_limit_dir would show the modified values as in
the /quota_limit_dir. It searches for the nearest parent that has quota limit
set and modifies the statvfs wrt that.

Change-Id: Ie10fae8999bddbb766b1dbeb881723ed80dce688
BUG: 1080296
Signed-off-by: Varun Shastry <vshastry@redhat.com>
Reviewed-on: http://review.gluster.org/7330
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Tested-by: Raghavendra G <rgowdapp@redhat.com>