Add filter against metrics with misplaced dots in blacklist example

This helps preventing issue #181
Chown created subdirs if USER specified

In a setup with:

LOG_DIR = /var/log/carbon and the
USER    = carbon

If the --instance parameter is supplied to multiple instances of each daemon,
the daemon will create subdirectories of LOG_DIR like carbon-cache-a,
carbon-aggregator-b, etc. However, these subdirectories are owned by the
user starting the daemon, not by the USER= specified in the config file.
Only the console.log will be created, because all the other log files
are created after the daemon switches USERs.

This change makes the daemon chown() the newly-create directories to the
configured user if one is configured. To keep this simple, it now creates
only one level of directory, so you can no longer set
LOG_DIR=/path/does/not/exist and have that entire hierarchy get created.

This is related to graphite-project/carbon#149, as it a typical cause of
failing to open these log files.
Demonstrate that hash positions can collide
Remove test running since trial handles this
Prevent hash ring positional collisions
Restore recursive mkdir on LOG_DIR

Revert part of 2bcd901a9e60f24a4c1c972bc3354969a8c8258e.
Up to three levels of directories may need to be created, if a user only
defines STORAGE_DIR and uses the --instance parameter.

Now, if you want every subdir under LOG_DIR to be owned by USER, you
must create all but the last directory beforehand and give it the
correct owner. Automatically chown()'ing each level of directory created
would have been too complicated.

Fixes #199.
carbon.conf comment clarification

MAX_CACHE_SIZE unit was not clear.
Force exact match of regex_pattern for carbon-aggregator rules.

In its current implementation the regex_pattern would match any metric that starts with the given pattern. Consider the following rules:

aggregated.histogram.p99        (10) = avg hosts.*.histogram.p99
aggregated.histogram.p999       (10) = avg hosts.*.histogram.p999

Currently the second rule would be treated as expected but the first rule would lead to an aggegated metric `aggregated.histogram.p99` which would in fact be equivalent to `avgSeries(hosts.*.histogram.p99,hosts.*.histogram.p999)`.

This patch forces exact matches of the regex_pattern, not only prefix-matches.
The length of the carbon-relay's per-destination queue is not visible.

This patch adds
carbon.relays.<hostname>.destinations.<dest-host>.relayMaxQueueLength,
a counter that records the maximum queue length for that destination
during the reporting period.
Remove an un-needed attempt to send a instrumentation stat.
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.
Update conf/storage-schemas.conf.example

Note about resolution and aggregation with example
Clean up the code a bit in the example client
- added --nodaemon flag to carbon, to run twisted service in --nodaemon mode