dog/farm: register vdi for 'snapshot load operation'

This will git rid of need that we have to manually check copy_policy of requests
in the plain store.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
sheep: kill is_erasure_obj()

Since we already register vdi for 'cluster snapshot load', we don't need
ugly is_erasure_obj() any more. Now we can use is_erasure_oid() to reliably
check if oid is ec object.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
sheep: don't call heavy md_get_info init_obj_path()

This will iterate all the objects of the MD before vdi states setup, causing
data inconsistency problems.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
sheep: store ec_index in the pathname instead of in xattr

This patch solves a performance issue that in the recovery, update_epoch() is
called to iterate all the objects to move stale objects into stale directories
this is fast for replication objects because oid_stale() doesn't access disks
at all. But for erasure objects, we have to read xattr for each one. This is
considerably slow for massive data deployment. For e.g, it might take more than
one hour for 6T data in 6 nodes cluster. Since update_epoch() is required to
run in the main thread, this means we can't process any requests during the
first phase of recovery.

Instead of storing 'ec_index' in the xattr of the object, we directly store it
in the pathname of ec objects, e.g, xxxoidxxx_1 indicate its ec index is 1 and
it is an ec object. By this way, we

- simplify the read/write path a bit
- no need to read disks at all for update_epoch()

Thus largely boost the update_epoch() and also boost normal read/write a bit.

With this patch, the disk layout for ec objects is changed from

oid       --> oid_index       [data  object]
oid.epoch --> oid_index.epoch [stale object]

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
dog/vdi: rework 'vdi object location' and 'vdi track'

Add a SD_OP_EXIST to check if an object exists in the specific node.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
sheep/recovery: fix a sefault when ->stop is set true

For multi-threaded recovery, if one thread set ->stop true and release rinfo,
other threads might null-deferenece rinfo and get segfault.

We should simply ignore ->stop in main thread and wait for run_next_rw() to be
called and safely run into the next recovery.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>