Hand off excess messages to SQS

After a certain backlog threshold is met, start sending incoming jobs to
SQS for later processing.  This should help with the condition where
autoscale-launched instances are unable to assist with a giant batch of
work that has already subsided after they finished launching.

It also includes a corresponding receiver that will activate when
otherwise idle and attempt to receive messages from SQS.

This still needs some work -- in particular, metrics like number of
offloaded messages should be collected and autoscaling should be
adjusted to take into account the fact that local queues will no longer
become very large, so should not be used as a criterion for autoscaling.
Replace server shutdown WaitGroup with implementation based on combiner

Combiner already tracks the in-flight job count and queue size,
deferring shutdown until this count is zero is a cleaner approach than
duplicating behavior.
Fix test for change in input
Remove unnecessary test setup step

This waitgroup was replaced with a combiner-based implementation in
a previous commit.
Source tracking

This adds a flag to Jobs that can be used to determine whether they came
from SQS or HTTP.  It's necessary for debugging and to ensure that jobs
aren't wastefully shuffled back and forth between the local queue and
SQS.
Properly handle message deserialization failure

The only thing to do is log it and delete the message, since we don't
want it to fail continuously.
Generate UUID outside of setup

This was removed from setup for some reason, so now has to be done at
deserialization time.
No longer dangerous, CombinerServer doesn't have a queue anymore
Don't print response unless an error occurs
Modify scale alarms to know about SQS

Since we overflow jobs to SQS once local queues reach a given threshold,
we can no longer use local queue size as a metric for when to scale up.
We can use the size of the SQS queue, but SQS reporting is only
refreshed in cloudwatch every 5 minutes.  The most responsive metric is
our custom excess one that tracks the net job count every minute.
Get rid of source tracking

This is not necessary  -- due to the way local and remote queues
currently interact, we don't need to differentiate between messages
received via HTTP and those received via SQS.
Simplify and remove unnecessary timer
No need to pass combinerserver anymore
Switch to croudmob's goamz fork for all aws functionality

We already used it for SQS because Canonical's project never supported
that service. In general it tracks amazon's feature set more closely
than launchpad.net/goamz.
Disable success notifications in test mode

Also, make absolutely sure that tests never trigger any amazon
modifications
Store redundant SQS queue length metric and use it to scale

Cloudwatch stores this queue for us, but it is 5 minutes behind reality
for some reason, which is a shame because it is the best metric to make
scaling decisions on.  To reduce latency, we can directly query SQS for
the approximate queue length every minute and bundle that up with our
existing custom metrics.  As a fallback, also use the automatically
reported CW queuelength metric as well, although it should always lag
the custom metric.