Pool-aware Scheduler Support

Cinder has been designed to take look each volume backend as a whole since day 1. The provisioning decisions are based on the statistics reported by backends periodically. Any back end is assumed to be a single discrete unit with specific set of capabilities and capacities offered and also these characteristics are constant through out the boundary of the storage addressed/managed by the back end. In reality this assumption is not true for many storage providers and as their storage managed can be further sub divided or partitioned into 'pools' to offer completely different set of capabilities and capacities. That is there are storage backends are a combination of storage pools rather than one big single homogenous entity. And usually volumes/snapshots can't be placed across pools on such backends. As a result, there are several obvious problems when using them with current Cinder:
1. A volume/snapshot that is larger than any sub-pool of the target backend be schedule the backend would fail;
2. A sub pool may not have enough space to serve consecutive request (e.g. clone volume, create snapshot) but while the entire backend appears to have enough capacity;
The issues are very confusing and result in inconsistent user experience. Therefore it is important to extend cinder to be aware of storage pools within backend and also use them as finest granularity for resource placement.