Prevent null aggregates via xFilesFactor=0.0

As per http://obfuscurity.com/2012/04/Unhelpful-Graphite-Tip-9, roll
up averages provided we have at least one data point.

Generally, null data is due to:

* check not running, and hence *zero* valid values. Should aggregate to
  'null'
* check is running, but is at a longer interval than the default
  retention of the metric.
* the sender of the metric is rather unreliable/lossy/high-latency.

This fix ensures that we only get null aggregate when all data points
are null.
Normalise carbon metrics to our default collectd interval

No reason to be different, and higher resolution on this is
useful.
Update default storage schema

I've knocked up a quick 'graphite calculator' -- https://gist.github.com/mikepea/19029ff5b944079c1b10

Based on this, we can afford to have the following policy:

Policy:             10s:10d,5m:400d,24h:20y
Send frequency (s): 10
Number of metrics:  1000
Number of hosts:    20

Total Datapoints per metric: 208900
Per-fragment Datapoints:     {"10s:10d"=>86400, "5m:400d"=>115200, "24h:20y"=>7300}
Size per metric:             2448KiB

Datapoints recd per second: 2000
Total disk space needed:    47813MiB

My reasoning:

* 50GB is not a crazy amount of space to allocate to the storage of
metrics for 20 hosts - roughly the limit of what we expect per graphite
cluster at a maximum.
* 1000 metrics per host is about the order of magnitude for a max number
of metrics per host (we do 100-300 by default with collectd, so plenty
of headroom)
* It is better to ensure that we have no aggregation for the general
use-case (10s:10d) -- looking at the most recent data. Aggregation =>
inaccuracies, and with graphite it's quite easy to accidentally
aggregate your data into an unusable or incorrect value. Storing for 10
days allows us to compare yesterday with 8 days ago (for example),
without any loss of precision.
* We need to aggregate at some point - 5m:400d gives us a decent accuracy
for over a year (and costs about the same in storage as our 10s:10d
policy).
* 24h:20y is really just to store per-day metrics for longer than 400d,
for metrics that are valid in per-day counts. It costs us nothing in
comparison.
Remove commented out ^carbon matcher

We have updated CARBON_METRIC_INTERVAL to match our 10s collectd interval,
so no need for the special case any more.
Merge branch 'resolution' of github.com:ministryofjustice/metrics-formula into resolution

Conflicts:
	metrics/files/graphite/conf/storage-schemas.conf