sheep: change a prototype of process_main() for obtaining sender information

This patch changes a prototype of process_main() for obtaining sender
information. It is useful for detecting which node issued operations.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: revive lock operation

Current sheepdog doesn't support vdi locking. This patch and
succeeding ones revive the feature. With this feature, more than two
clients (including QEMU and tgt) are not allowed to open same VDI at
the same time.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: add a list for storing information of all clients

This is a preparation patch. Currently we don't have a way of
enumerating entire information of clients. This patch adds a single
list for doing it.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: associate client info and locked vdi

This patch associates client info and locked vdi. The association is
required for releasing locked VDI in a case of unexpected death of
clients.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: add an API for releasing VDI

There are 3 cases of VDI releasing:
1. client processes (QEMU and tgt) releases explicitly
2. client processes (QEMU and tgt) die suddenly
3. node leaves

All of them must be handled in a single policy because they must have
same effect. Currently, the case 1 and 3 are supported. This patch
makes the mechanism general and lets destroy_client() use for
supporting the case 2.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: unlock existing lock in a case of double locking

Typical sheepdog clients issues two or more locking request
(SD_OP_LOCK_VDI, typically issued in the function
find_vdi_name() of clients) during their lifetime because it is
required when snapshots of their VDIs are taken. In such a case, an
existing lock becomes needless because the lock points snapshot. This
patch add a release procedure for the case.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
dog: use GET_VDI_INFO unconditionally in dog

dog command needs to read/write inode objects for various operations
e.g. taking snapshot. The operations shouldn't be prevented by locks
acquired by other clients (QEMU and tgt). SD_OP_GET_VDI_INFO doesn't
try to acquire the lock, so dog command should use it unconditionally.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: snapshot and collect vdi state during joining to cluster

Newly joining sheep must know which vdi is locked or unlocked. For
propagating the state, new sheep must copy it from existing nodes
during join process.

This patch implements a solution for this. Below is the brief
description:
1. When a cluster accepts newly joining node, every existing node take
   a snapshot of vdi state at the epoch.
2. Newly joining node copy it via a newly defined request.
3. After applying the copied state to its internal state, the new
   sheep issues discard request to existing nodes.

With this scheme, new sheep can know which vdi is locked or unlocked.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
sheep: log and play locking/unlock information in newly joining node

We need to handle a case like below:
1. a new sheep joins to cluster
2. before the new sheep finishes copying snapshot of vdi state, a
   client issues lock request
3. the new sheep finishes copying the state

If this execution pattern happens, the lock information produced in
the step 2 cannot be obtained by the new sheep. This patch solve this
problem.

Brief description of the solution:
When sheep joins cluster, it sets its status as
SD_STATUS_COLLECTING_CINFO. When the sheep receives lock/unlock
requests in this state, it logs the operation in its internal
queue. After copying snapshot (step 3), the sheep play the log and
construct complete locking status.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>