Appropriate sharing/separation between metering & metric/alarms infrastructure

By default, the metrics gathering underlying ceilometer alarming can share the same infrastructure as the metering functionality.

However in realistic deployments, we envisage that operators may want to reflect differing requirements by separating off the transport conduit and storage elements.

Also the metering data is not always currently in a form suitable for consumption by the alarming logic.

The actionable requirements are:

1. Support a non-AMQP conduit more suited to loss-tolerant metric data, e.g. a UDP-based publisher in the agent and consumer on the collector side.

2. Test and document separation of the metering and metrics stores, with the same schema but differing retention periods specified. An extreme form of roll-up could be
used initially, whereby the metric data beyond a certain age are simply dropped via the native TTL implemented by the underlying DB.

3. Provide transformers to use a sampling approach to convert the cumulative instance meters to equivalent guage values which are far more useful for alarming (in the style of CPU time => CPU utilization %).