INT-2426: Add `Idempotent Receiver` EIP

JIRA: https://jira.spring.io/browse/INT-2426

INT-2426: pushed `final` modifier fix for Java 6 compatibility

INT-2426: Rework logic to the `MetadataStore`

INT-2426: `IdempotentReceiver` -> `IdempotentReceiverInterceptor`

* Move `Idempotent Filtering` logic to the `IdempotentReceiverInterceptor`, which should be applied as a regular
AOP `Advice` to the `MessageHandler#handleMessage`
* Provide an xml component `<idempotent-receiver>`
* Introduce `IdempotentReceiverAutoProxyCreator` to get deal with `IdempotentReceiverInterceptor` and `MessageHandler`s.
The `Proxying` logic is based on the mapping between interceptor and `consumer endpoint` `ids`
* Introduce `MetadataStoreSelector` along side with `MetadataKeyStrategy` and `ExpressionMetadataKeyStrategy` implementation

INT-2426: Introduce `IdempotentReceiver` annotation

Add `IdempotentReceiverIntegrationTests` in the JMX module to be sure that all proxying works well.

INT-2426: Polishing according PR comments

* Rename `IdempotentReceiverAutoProxyCreatorInitializer`
* Add support for several `IRI` for the one `MH`
* Polishing JavaDocs

INT-2426: Add `What's New` note

Doc Polishing.

More Doc Polishing

Use Timestamp (hex) instead of Id for Value

Facilitate cleanup.
INT-3341: Add Redis Queue Gateways

Add RedisQueueOutboundGateway and RedisQueueInboundGateway

JIRA: https://jira.spring.io/browse/INT-3341

add test

fix format issue

change expectmessage to extractpayload, fix test potential bug

fix copyright year

fix format and naming issue

fix as Artem's comments

fix as Artem's comments

change boolean condition judgement

INT-3341: Polishing

Minor Doc Polishing
[artifactory-release] Release version 4.1.0.RC1
[artifactory-release] Next development version
INT-3539: Fix `ChannelSecurityInterceptorBPP`

JIRA: https://jira.spring.io/browse/INT-3539

Previously the `ChannelSecurityInterceptorBeanPostProcessor` eagerly loaded all beans from its `afterPropertiesSet`
to retrieve the `ChannelSecurityInterceptor`s. According to the `BeanPostProcessor` nature the `afterPropertiesSet` hook isn't legitimate.
It may cause some bad side-effects for other beans, which might not been initialized yet.

Rework `ChannelSecurityInterceptorBeanPostProcessor` to accept `Collection<ChannelSecurityInterceptor>` in the ctor.
Rework `SecurityIntegrationConfigurationInitializer` to iterate over `BeanDefinition`s to determine those of them, which
are `ChannelSecurityInterceptor` or `ChannelSecurityInterceptorFactoryBean`.

**Cherry-pick to 4.0.x**
INT-3540: Add `<scatter-gather>` to the `<chain>`

JIRA: https://jira.spring.io/browse/INT-3540
INT-3542 Clarify Docs Regarding Inner Beans

JIRA: https://jira.spring.io/browse/INT-3542
INT-3543: Remove `context.close()` from tests

JIRA: https://jira.spring.io/browse/INT-3543

Quoting Sam Brannen:

> However, one should *never* programmatically close the injected application context in a test,
since the Spring TestContext Framework caches all contexts across the entire JVM process.
If you need to close a context after a test method or test class for some reason,
the only supported and reliable mechanism is `@DirtiesContext`.

**Cherry-pick to 4.0.x**
INT-3457 Fix stop(Runnable) in AbstractEndpoint

JIRA: https://jira.spring.io/browse/INT-3547
JIRA: https://jira.spring.io/browse/INT-3546

INT-3486 changed stop(Runnable) so that it could be
overridden by subclasses, to allow separation of the
`stop()` and `callback` invocation.

However, the refactoring changed the logic such that
the `running` field is not reset, causing `doStop()` to
be called even when the component was not running.

Reset the running field.

Also, the MQTT inbound channel adapter did not test
for a `null` `client` in `doStop()`.
INT-3548 Fix @Payloads Annotation

JIRA: https://jira.spring.io/browse/INT-3548

Refactoring in 4.1 broke the `@Payloads` annotation in the
`MessagingMethodInvokerHelper`.

The test case missed this because it explicitly declares
`@Payloads List<Integer>` which is actually handled by the
case below:

````java
else if (Collection.class.isAssignableFrom(parameterType) || parameterType.isArray()) {
	if (canProcessMessageList) {
		sb.append("messages.![payload]");
		...
````

`List<?>` triggered

````java
else if ((parameterTypeDescriptor.isAssignableTo(messageListTypeDescriptor) || parameterTypeDescriptor
				.isAssignableTo(messageArrayTypeDescriptor))) {
	sb.append("messages");
	...
````

- Add back the logic to detect `@Payloads`.
- Remove `@Payloads` from the existing test.
- Add a new test that uses `List<?>`
INT-3549 Fix AMQP o-c-a Validation

JIRA: https://jira.spring.io/browse/INT-3549

`afterPropertiesSet()` checks for `NullChannel` to determine
whether a correlation expression is needed for confirms.

This code fails when `nullChannel` is proxied.

Extract the type before testing.
INT-3538: Docs for Scatter-Gather

JIRA: https://jira.spring.io/browse/INT-3538

Phase #1: `Scatter-Gather`

S-G Doc Polishing

INT-3538 Add `requires-reply` to `scatter-gather`

Final S-G Doc Polish
INT-3538: Docs for Routing Slip

JIRA: https://jira.spring.io/browse/INT-3538

INT-3538-2: `RoutingSlipHeaderValueMessageProcessor` improvement

Since `HeaderEnricher` populates `beanFactory` to its `HeaderValueMessageProcessor`s,
there is no reason to specify `RoutingSlipHeaderValueMessageProcessor` as a separate bean.
Therefore the `IntegrationEvaluationContextAware` may not be reached.
Remove its support from `RoutingSlipHeaderValueMessageProcessor` and just rely on the `setBeanFactory`

RS Doc Polishing
INT-3538-3: Docs for `Idempotent Receiver`

JIRA: https://jira.spring.io/browse/INT-3538

I-R Doc Polishing
INT-3545: Don't AutoStart HeaderChannelRegistry

JIRA: https://jira.spring.io/browse/INT-3545

Previously, the `DefaultHeaderChannelRegistry` was auto-started.
This caused the reaper to run and eventually start all the
`taskScheduler` threads, even if the registry was not being used.

- Defer the `start()` until the first channel is stored.
- Do not start the reaper if the bean has been explicitly stopped.
- Deprecate the implementation of `SmartLifecycle`.
INT-3555: Fix Header Channel Mapping

JIRA: https://jira.spring.io/browse/INT-3555

Previously, `replyChannel` and `errorChannel` headers were
unconditionally dropped in `AbstractHeaderMapper`. This was
changed in 4.1.0.M1 to allow these headers to be transmitted
in the case that they were translated to a String by a
`HeaderChannelRegistry`.

However, we should still drop these headers if they reference live
`MessageChannel` instances.