[BZ 1114202] handle failures in aggregating 1 hr and 6 hr data

Previously there were basically two phases to data aggregation. First, we would
aggregate raw data from any past time slices, and if necessary recompute 6 hr
and 24 hr data. Then we would compute the 1 hr data (and 6 hr and 24 hr data if
necessary) for the current time slice. If there were errors computing either
6 hr or 24 hr data for the current time slice, we would not recompute it unless
we wound up recomputing 1 hr data that fell in those time slices.

These changes ensure that we will recompute 6 hr and 24 hr data. They also
simplify the implementation as PastDataAggregator is being deleted. It is
no longer necessary. Now we first scan the raw index starting at some point in
the past. Right now it is hard coded to 48 hrs prior to the current hour, but
I will make it configurable. We compute 1 hr data for any schedule ids we find
in the index for time slices up to the current time slice. We then repeat this
for 1 hr and 6 hr data.
[BZ 1114202] use separate thread pools, more clean up

AggregationManager's life cycle now coincides with MetricsServer. It also now
has its own dedicated thread pool as does MetricsServer.
[BZ 1114202] fix some logging