Make sending stats more asynchronous and batched.

All stats are now put into the relay's CarbonClientFactory's queue.

The queue is now implemented using a collections.deque.  Prior to this
patch, multiple copies of the majority of the queue would be copied
after an stats built up, e.g. after an outage between a relay and one
of its destinations.  If that queue was large, multiple copies of the
vast majority of the list would be copied over and over again.  Lots
of potential for thrashing there.

Now, when a stat is enqueued a write is scheduled via
twisted.internet.reactor.callLater().  A configurable delay, which
defaults to .0001 seconds, is given to allow more stats to enter the
queue, and once that time is up, the queue will be cleared.

Now, when the queue is cleared, once MAX_DATAPOINTS_PER_MESSAGE is
retrieved from the queue and sent, the callLater method mentioned
above will be used again to schedule the next batch.  The delay for
this should be effectively zero (0.000001).

The reason that callLater is being used instead of a loop is to
release the lock on the event loop, allowing metrics to flow in
asynchronously.  This is an attempt to fix the same problem that
https://github.com/mleinart/carbon/commit/9ac8202b54ff4f82a6f7c51529b1d671bb1d56a5,
is trying to fix, but without introducing out-of-order stats.
Fix some relay-related stats not getting updated.
Updated the comments in carbon.conf based on my observations of how
the recent changes to the relay can affect a cluster.
Slow down the subsequent invocations of sendQueued() so that the
destination doesn't get pummeled as badly.
Prioritize stats relating to the router.

Now that there's a single deque per destination, we can put router
stats into the deque on the left.  To do that, when a router is
initialized the metricReceived and the metricGenerated callbacks are
different - they're now pointed at the
client_manager.sendHighPriorityDatapoint method, which will push onto
the left of the deque.

The goal here is that when there's a failure due to the router being
overwhelmed, the routers own stats tell that story.  But currently
they're not likely to be among the first stats pushed out, and so
they'll be lost.  The new sendHighPriorityDatapoint method will ignore
the maximum queue size, and it'll cause these stats to go out first in
any batch.
The last change caused all metrics to be special.  Now only
relay-specific metrics should be treated as special.
When delivering metrics to a destination a long way away, the relay
can run into poor internet weather after a time.

This patch checks for the quality of the connection in a given
CARBON_METRIC_INTERVAL.  If the number of metrics received in the
interval is greater than MIN_RESET_STAT_FLOW, and the ratio of metrics
received to metrics sent falls below MIN_RESET_RATIO, then the
connection will be re-set.  This behavior can be enabled by setting
USE_RATIO_RESET=True in the config for the relay.

This will only work for a setup that expects all inbound stats to be
sent outbound as well.  A configuration where stats are filtered would
require that an extra relay is set up on the same host or on a very
nearby host that will act as the quality monitor relay.  The
first-layer relay can filter the stats, the second-layer relay can
then forward all stats it receives and monitor the connection.

Bugs fixed:

- In some places in client.py I had been referring to "settings" as
  "config" because of a typo.

- The specialMetricGenerated Event wasn't sending events.  I've
  reverted to using the regular metricGenerated Event until I can
  figure out what I'm missing.
Make the connection reset metric a continuous line.
Merge pull request #92 from pcn/use-deque

Performance/stability improvements in the relay