aggregator_new: allocate more "future" buckets

By having more future buckets, we have more room to "slack", because if
we're still behind, the future buckets will just get populated, hoping
we end up in the now soon enough, which could be the case if we have a
lot too do all the time.
aggregator: avoid thundering herd of expirations

With many aggregations created at almost the same time, they expire at
almost the same time as well, so introduce a splay to try and spread the
expiration (sending out metrics) a bit.
relay: submit internal generated metrics through a server

When the dispatchers get really busy, connections are not handled
timely.  This causes blocking writes to the internal connection pool to
be stalled for a potentially long time.  This is no problem for a
separate thread (like the server's are modelled on), but it is for
something which doesn't expect sending out metrics to block, such as the
current design of collector and aggregator.  As a result, under stress,
statistics would get lost (blocking for long, eventually failing), and
aggregations would be way out of time due to the long blocks, causing
essentially all incoming aggregation data to be dropped because they are
considered to be too far in the future (since aggregation rotation
didn't happen).