Filters Update

[69mb]

@ekala A couple of changes to the Consumer and Publisher classes that allow us to make use of RabbitMQ's reply_to and correlation_id properties better.

This way we can keep multiple drop queue processors and filters running and also restart any application without losing drops.

[ekala]

@69mb Yeah, the transient callback queues do scale much much better. For cases where the drop queue processor has to be restarted, won't the drops already submitted to the metadata exchange have a stale reference to the callback queue in which case they'd have to be re-submitted with a valid callback queue?

[69mb]

The transient queue will no longer exist when the dropqueue is restarted and RabbitMQ will simple discard and drops destined for this queue.

Since the drops were left pending in the dropqueue, they will be resubmitted when the dropqueue is restarted or picked up by another instance.

[ekala]

Looks good for a merge.