Initial format for message retry handler.
Commit of example, retry_handler and some other logic to handle the retry queue setup.
Changes to queue to pass opts into handlers, worker to use hdr not hdr.delivery_tag, max_retry_handler to create and bind required queues.
Merge branch 'maxretry' of https://github.com/otherlevels/sneakers into yw-maxretry
Maxretry Handler

This was originally started here:
https://github.com/otherlevels/sneakers/tree/maxretry and discussed as
a sneakers issue here: https://github.com/jondot/sneakers/issues/18. I
took this, updated the rest of sneakers to work with it and wrote tests
of both Handlers to ensure things are still working as expected. NOTE:
This is a breaking change in that any Handlers out there will no longer
work as the interface has changed. I expect there may be one more
interface-changing commit to follow on to this depending on how to
tackle the metrics issue.
Merge pull request #1 from Yesware/yw-maxretry

Maxretry Handler
Make Maxretry Handler only retry per-queue.

This required a bit of a more complicated setup, but before this change,
the retry was retrying failures to the exchange which meant if you had a
fanout exchange, every queue would see the retry, not just the queue
that the failure occurred upon. To fix this, I created another exchange
and bound the queue you're retrying on to this one (in addition to the
exchange it was currently bound to). This allows us to put the retry
dead lettering to it and it will ONLY send the message to the queue
you're attempting retry on. Updated the example to demonstrate this more
clearly.

As part of this I made a couple of changes:
- Add another argument to handler constructor
- Use worker config when creating the handler.
- Fix bug in worker where it didn't respect incoming options. This
  didn't look to be used anywhere.
Merge pull request #2 from Yesware/yw-make-maxretry-per-queue

Make Maxretry Handler only retry per-queue.
Log backtraces if present when jobs fail.

This is already done on sneakers master, but by logging each line of the
backtrace on a separate line. While this looks nice, it makes it very
hard for log tools to get the entire backtrace by searching for lines
that contain "ERROR" for instance. I'll probably merge sneakers master
into our fork and undo that change so we are all sync'd up again.
Merge pull request #3 from Yesware/log-backtrace

Log backtrace
Merge branch 'master' into merge-upstream-master

Conflicts:
	lib/sneakers/queue.rb
Merge upstream master and cleanup backtrace logging

Undo the backtrace logging how it was done and do it on a single line.
Also include some more information so it's easier to find all timeouts,
all unexpected errors, etc.
Merge branch 'yw-master' into merge-upstream-master

Conflicts:
	lib/sneakers/worker.rb
Improve logging in Maxretry handler and fix fallthrough metric in worker

We needed some more insight into when a worker was retrying a job. Would
be nice to have stats too, but that really requires that these handlers
also have access to the worker. I think eventually we'll replace the
exchange and queue with the worker as an argument. Until then, this
logging should give us enough information to know how often it's
happening and possibly why.

Also the fallthrough case is noop when Sneakers cannot interpret the
response. The metric being collected was retry which was wrong as the
handler's retry method was not called and instead the noop method was.
Better to keep these two in line.
Merge pull request #4 from Yesware/merge-upstream-master

Merge upstream master
Merge pull request #5 from Yesware/improve-logging-in-maxretry-handler

Improve logging in Maxretry handler and fix fallthrough metric in worker
Reject a JSON payload with error details

When the retry worker runs out of retries and sends a message on to the
error queue, capture as much as we can so you have some hope of
understanding what's going on. This will require a more complicated
replay than simply moving them off this queue onto another exchange, but
that seems reasonable.
Merge pull request #6 from Yesware/reject-json-with-details

Reject a JSON payload with error details
Add option :queue_durable to allow creation of a non-durable queue
Merge pull request #7 from Yesware/option_for_nondurable_queue

Add option :queue_durable to allow creation of a non-durable queue