enable cloning for rbd-backed ephemeral disks

Currently when using rbd as an image backend, nova downloads the
glance image to local disk and then copies it again into rbd. This
can be very slow for large images, and wastes bandwidth as well as
disk space.

When the glance image is stored in the same ceph cluster, the data is
being pulled out and pushed back in unnecessarily. Instead, create a
copy-on-write clone of the image. This is fast, and does not depend
on the size of the image. Instead of taking minutes, booting takes
seconds, and is not limited by the disk copy.

Add some rbd utility functions from cinder to support cloning and
let the rbd imagebackend rely on librbd instead of the rbd
command line tool for checking image existence.

Add a direct_fetch() method to the image backend, so backends like rbd
can make optimizations like this. Try to use direct_fetch() for the root
disk when it comes from an image, but fall back to fetch_to_raw() if
direct_fetch() fails.

Instead of calling disk.get_disk_size() directly from
verify_base_size(), which assumes the disk is stored locally, add a new
method that is overridden by the Rbd subclass to get the disk size.

Implements: blueprint rbd-clone-image-handler
Closes-Bug: 1226351
Change-Id: I9b77a50206d0eda709df8356faaeeba35d232f22
Co-Authored-By: Dmitry Borodaenko <dborodaenko@mirantis.com>
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Signed-off-by: Zhi Yan Liu <zhiyanl@cn.ibm.com>
Signed-off-by: Dmitry Borodaenko <dborodaenko@mirantis.com>
Use Ceph cluster stats to report disk info on RBD

Local disk statistics on compute nodes are irrelevant when ephemeral
disks are stored in RBD. With RBD, local disk space is not consumed when
instances are started on a compute node, yet it is possible for
scheduler to refuse to schedule an instance when combined disk usage of
instances already running on the node exceeds total disk capacity
reported by the hypervisor driver.

Change-Id: I9718c727db205b6f2191f8435583391584e96e6e
Closes-bug: #1332660
Signed-off-by: Dmitry Borodaenko <dborodaenko@mirantis.com>