Make GET /metrics/find able to take multiple query= params.

This makes it possible for Graphite to query the backends in
CLUSTER_SERVERS more efficiently.

Note that this only works in case of format=pickle or
format=completer; I was unsure what the semantics of a multi-query
request with format=treejson should be, so I left it unimplemented.

Also note that this doesn't yet improve the way in which Graphite
makes requests to the backend Graphites in CLUSTER_SERVERS; that will
happen in a subsequent commit.
Fetch data in bulk for better performance on high-latency networks.

Instead of doing one-by-one parsing and evaluation on each target
parameter, we now use a three-pass method across all targets.

Pass 1: parse each target= parameter and gather all the metrics
(e.g. swap.used) and patterns (e.g. cpu.*.system) that need to be
retrieved.

Pass 2: Retrieve the data. We start by looking on the local system for
any files that satisfy the targets, and then for any unsatisfied
targets, issue "GET /metrics/find/?query=...&query=..." requests. One
find request is issued per server in CLUSTER_SERVERS.

Once all the desired metrics have been located, "GET
/render?format=pickle&target=metric1&target=metric2&target=..."
requests are issued to retrieve the data. Again, one request is issued
per server in CLUSTER_SERVERS.

Pass 3: perform another pass over the parse tree, filling in metrics
and patterns with the retrieved data, calling functions, and so forth.

In most cases, this reduces the number of HTTP requests to each
backend server from 2 per metric (one GET /metrics/find, one GET
/render) down to just 2 for everything. For complex graphs using lots
of metrics, this is a significant performance increase.

This makes Graphite much faster on high-latency networks. For example,
consider a CPU-usage graph for a small cluster of application servers;
if we're graphing two metrics per and there are 10 machines with 8
cores each, that's 2*2*10*8 = 320 HTTP requests per backend. Given a
50ms round-trip time, this graph would take a minimum of 16 seconds to
render. Using bulk fetching improves that to 100 milliseconds.

There are still some cases where more than 2 requests will be
made. Calls to any function which calls evaluateTargets will result in
another set of requests to the backends. The functions in question are
useSeriesAbove, holtWinters*, timeShift, smartSummarize, and hitcount.
Fix crash for patterns that don't match.

Also remove unused import lines.
Add missing logging for JSON render requests
Tons and tons of logging.

Added a UUID to each request so that you can easily correlate lines
within a log file and also lines from other log files.

This all proved really helpful when trying to figure out why certain
requests took so long to load, so I'm checking it in.

You'll need to turn on LOG_RENDERING_PERFORMANCE,
LOG_CACHE_PERFORMANCE, and LOG_METRIC_ACCESS to get all these logs to
appear.
Speed up functions.safeMul.

On one graph, this took the time spent in scale() from ~5s to ~2s.
Inline multiplication in scale() and scaleToSeconds().

This produces about an 80% speedup in those two functions (that is,
the new runtime is about 20% of the old runtime).

Turns out that making hundreds of thousands of function calls in
Python is expensive.
Fix doc string for nonNegativeDerivative
Send txId for remote render requests.

This way, you can correlate all the logging for a single client
request across multiple Graphite servers in a cluster.