AMQP-225 Add Support for External Executor

If no ExecutorService is provided when creating a new
connection, Rabbit uses a default fixed thread pool
executor with 5 threads.

You can now specify an executor on the
<rabbit:connection-factory/>.

Due to limitations in the Rabbit API,
this must either reference a ExecutorService (such as
one returned by Executors.new...Executor() methods, or
a Spring ThreadPoolTaskExecutor, such as one defined
using the <task:executor/> element.

The underlying API (newConnection()) with no arg
calls (newConnection(null)), so it is safe to
always use newConnection(exec), and not test for
null.
AMQP-206 Support Rabbit HA

- Configure a list of addresses in ConnectionFactory
- Allow arguments (e.g. HA) for temporary reply queue creation

AMQP-206 Add queue-arguments Attribute

<queue/> now supports either <queue-arguments /> element
or a queue-arguments attribute which is a reference to
a <queue-arguments /> bean.

<queue-arguments /> is promoted to a top-level bean,
allowing for re-use, such as...

    <rabbit:queue-arguments id="haArgs">
	<entry key="x-ha-policy" value="all" />
    </rabbit:queue-arguments>

    <rabbit:queue name="si.test.queue" queue-arguments="haArgs" />

AMQP-206 Fix Parser Tests

AMQP-206 ReConnect To Mirrored Queue

If a consumer is connected to a mirror (slave), and the
master dies, the queue is moved. The consumer is given a
cancel notification, indicating we need to reconnect.

However, the move might not be complete, so we retry the
queue declaration a number of times before failing.

AMQP-206 Polishing

Cleanup retry counter name; trap exception on cancel of
temporary reply queue.

AMQP-206 Add reply-queue to RabbitTemplate

Allow specification of an explicit queue for replies. Adds
a correlation header to sendAndReceive messages (spring_reply_correlation)
which is used to correlate replies on the reply queue.

The queue is supplied to the template via the reply-queue
attribute; the template must be added as a <listener/> to a
<listener-container/> for the same queue. For example...

    <rabbit:template id="amqpTemplate" connection-factory="connectionFactory" reply-queue="si.test.replies" />

    <rabbit:listener-container id="replyContainer" connection-factory="connectionFactory" task-executor="reply-exec">
    	<rabbit:listener ref="amqpTemplate" queues="si.test.replies"/>
    </rabbit:listener-container>

    <rabbit:queue name="si.test.replies" queue-arguments="haArgs" />

AMQP-206 Stack Reply Correlation

Stacks (pushes/pops) correlation when using a fixed queue for
replies in sendAndReceive methods.

Now supports

templatsendAndReceive()->listener->templateSendAndReceive()->
   listener->templateSendAndReceive->...

and the replies get correlated in each template appropriately.

AMQP-206 Polishing

Add exclusive test for addresses attribute; add parser test.

AMQP-206 Polishing

Improve configuration of reply-queue listener on rabbit template.
Previously a disjoint listener was required. Now the listener
is a child element of the template itself.

	<rabbit:template id="withReplyQ" connection-factory="connectionFactory" reply-queue="reply.queue">
		<rabbit:reply-listener />
	</rabbit:template>

The reply-listener is a full-blown listener container, but uses the
template's connection factory and so that attribute, as well as the
message-converter is disallowed at run-time.

AMQP-206 Polishing

Remove disallowed attributes from <retry-listener/> child element
in schema.

AMQP-206 Reference Documentation

Update docs with addresses attribute on ConnectionFactory and
reply-queue on template.
AMQP-213 Initial Commit

Initial Commit

Add support for multiple acks in one call.

AMQP-213 Polishing

Move confirmation state to PublisherCallbackChannel. Allows
the RabbitTemplate to handle confirms from multiple
channels.

Remove unnecessary synchronization.

Add tests for multiple threads - verifying the
functionality when more than one thread concurrently
uses the template.

NOTES: The CF cache size must be large enough
to cover the number of required channels - otherwise
the channel is closed before the confirms are received.

This could be alleviated by not closing channels if
P.C. are turned on.

Each PublisherCallbackConnection has two maps, the
first map (seqToListener) identifies which listener
gets the confirmation. The second map (pendingConfirms)
is a map of maps where the key is the listener and
the value is a map of pending confirms for that
listener. This map is given back to the listener
when registering.

In this way, the Rabbit template does not need to
hold a reference to every connection he has used.
Instead, when a connection is closed, the listener
is informed via a call to removePendingConfirmsReference().

The listener  uses the pending confirms maps to
determine if any confirms have expired.

Add test for two templates sharing the same
factory, ensuring the appropriate template
gets the confirmation.
AMQP-213 Polishing
AMQP-213 Add Support for Basic.Return

The rabbit template will be registered to receive return
messages if it is provided with a ReturnCallback. Either
mandatory or immediate must also be set for returns.

mandator and immediate are ignored if no callback is provided.

AMQP-213 Polishing

The RabbitTemplate can only support one each of
ConfirmCallback and ReturnCallback because there
is no way to correlate back to the caller.

In situations where more than one client is needed,
each needs its own RabbitTemplate.

The connection factory, and hence the connection and
channels, can be shared across templates.

AMQP-213 Add Namespace Support for Returns

Attributes added to template for mandatory, immediate,
return-callback.

Also confirm-callback for confirms.
AMQP-213 Return Reply Code Etc

Pass the reply code, reply text, exchange, and
routing key back to the client on returns.
AMQP-213 Polishing

Fix non-default exchange on convertAndSend.
AMQP-213 Polishing PR Review