Rationalize get_resources for mongodb

Fixes bug 1288372

Previously the performance of the /v2/resources API without
constraints degraded sharply as the size of the meter collection
grows, regardless of the number of known resources.

We rationalize the underpinning storage driver method for mongo
so as to rebase the query on the much smaller resource collection.

This requires a subtle change in the semantic of the first and
last sample timestamps which decorate the resource representation.
These values are now defined respectively as being not later than
youngest sample, and not earlier than the oldest timestamp, known
for each resource.

In order to maintain support for "tight" timestamp constraints
on resource queries, we adopt a hybrid approach. For resource
queries without timestamp constraints, we optimize with a simple
query on the resource collection, but revert to a map-reduce on
the meter collection for timestamp-constrained queries.

The logic being that when one makes a resources query constrained
by timestamp, one is essentially asking a question about samples,
hence prepared to incur the cost of a query on the meter collection.
Whereas for other constraints (user_id, project_id, source etc.)
on the resources queries, one is more asking a question purely
related to the resources themselves.

Change-Id: Ifbf8932b4164f62bfda1cb3b8b9afe181051bc52
Added documentation for selectable aggregates

Documented available aggregate functions
and added example syntax showing how to use
improved Statistics API, which allows the user to
selectively access aggregate functions. Also
documented the Capabilities API, which allows
the user to find out what functionality is supported
by their storage driver.

Closes-Bug: #1290924
Change-Id: I9739d2102baf6040de017843ae20391c4c9b6fff
Merge "Rationalize get_resources for mongodb"
Merge "Added documentation for selectable aggregates"