INT-3516: Allow `Optional<>` in POJO Method Args

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

* Add `Optional<>` support for `@Header` in the `MessagingMethodInvokerHelper`
* Add `Optional<>` test-case
* Change `sourceCompatibility` for test to the Java 8

INT-3516: Revert SF version to 4.1.1

Add Docs on the matter

Fix WS Tests; Revert StubJavaMailSender
INT-3520: Add Reactor's `PersistentQueue` Support

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

INT-3520: Use `Condition` to wait items in the `Queue`

INT-3520: Reworking to the `Semaphore(0)`

* Implement 'artificial infinite wait'
* Add distributed test with infinite `receive()`

INT-3520: Correct usage of `Semaphore`

Minor Doc Polishing
INT-3516 Fix JPA Build Error

https://build.spring.io/browse/INT-B41-121
INT-3519 Add Poll Skip Advice

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

Add a mechanism to allow skipping polls, perhaps
because of some downstream condition.

INT-3519: Polishing
INT-3536 Fix Mail Receiver Regression Issue

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

The fix for opening multiple IMAP connections in the idle
adapter inadvertently removed the check for the store being
open.

Add `connectStoreIfNecessary()` and test case.
INT-275: Implement Scatter-Gather Pattern

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

In addition fix the `Lifecycle` issue in the `ServiceActivatorAnnotationPostProcessor`

Add Namespace support, Addition tests
   and fix some typos in the XSD

INT-275: Fix failed tests

INT-275: Fix for `replyChannel` Header

Add `sync` reply test-case

INT-275: Make `ScatterGatherHandler` sync

Fix some `MessageHandler`s from `SmartLifecycle`

INT-275: Fix `ScatterGatherHandler.handleRequestMessage` logic

INT-275: Fix `ScatterGatherHandler` JMX proxying issues

* Make `AbstractCorrelatingMessageHandler.getMessageStore()` as `public`
* Move `ScatterGatherHandlerIntegrationTests` to the JMX module to be sure that `ScatterGatherHandler`
works well with `@EnableIntegrationMBeanExport`
* Add xml config sample how to use an internal gatherer's `MessageStore` in the `MessageGroupStoreReaper`
* Add `What's New` notice
INT-3537 RemoteFileTemplate Close Stream

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

Stream not closed if session cannot be created.

Add `try {} finally {}`.

__cherry-pick to 4.0.x, 3.0.x__
Speed Up Mongo Build When No Mongo

@Rule used a 10 second connection timeout.

Polishing
INT-3535: Fix `JmsHM` to not override properties

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

Previously when `DefaultJmsHeaderMapper` overrided values, which had been able to be populated by the `MessageConverter`.

Since `MessageConverter` result has a precedence which is closer to JMS, skip those custom `MessageHeaders` which already has been populated by `MessageConverter`
INT-267: Implement Routing Slip Pattern

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

The implementation looks like:
* There is the `ROUTING_SLIP` header to keep the list of bean ids;
* The `ROUTING_SLIP_INDEX` header keeps track of current `index` in the `ROUTING_SLIP` header;
* `ROUTING_SLIP` List can contain channel names or bean references for the `RoutingSlip` strategy implementations.
They are differentiated with `@` prefix;
* The `<header-enricher>` adds `<routing-slip>` sub-element to specify the comma-delimited value for desired `ROUTING_SLIP` for the downstream flow;
* The `AbstractReplyProducingMessageHandler` adds the logic to get deal with `ROUTING_SLIP` List and the algorithm is:
    - If `ROUTING_SLIP` isn't `null` we build `AtomicInteger` for the current `routingSlipIndex`;
    - the recursive `getReplyChannelFromRoutingSlip` should return a channel name or `null`;
    - if current `ROUTING_SLIP_INDEX` if for the `RoutingSlip` strategy, we check its result for `null` and `incrementAndGet()` the current index or not;
    - for the simple channel name value from `ROUTING_SLIP` list we just `incrementAndGet()` the current index and return the value;
    - the new `ROUTING_SLIP_INDEX` is populated to the headers of new reply message.
* Polishing for `AbstractMessageSplitter`

**TODO**: Docs and applying `RoutingSlip` algorithm for the `AbstractCorrelatingMessageHandler`

INT-267: Move `replyProducing` logic `ARPMH` -> `AMPH`

* Rework `AbstractCorrelatingMessageHandler` to use methods from super class
* Rework `MessageHandlerChain.ReplyForwardingMessageChannel` to use `produceReply`
* Rename `RoutingSlip` -> `RoutingSlipRouteStrategy`
* Add `ExpressionEvaluationRoutingSlipRouteStrategy`

Now `routingSlip` header can be configured like:

```
<routing-slip value="channel1; #{@routingSlipRoutingPojo.get(request, reply)}; @routingSlipRoutingStrategy; #{request.headers[myRoutingSlipChannel]}; channel6"/>
```

Where `;` is used as delimiter, because of `,` in the method invocation from SpEL.
The simple literal (`channel1`) is just a `MessageChannel` `id`.
`@` is used for `RoutingSlipRouteStrategy` bean reference.
`#{...}` used for SpEL.
The `HeaderEnricherParserSupport` parses this `value` to the `List<String>` - a set of bean names, where any SpEL is wrapped
to the `ExpressionEvaluationRoutingSlipRouteStrategy` bean definition

INT-267: Introduce `RoutingSlip` Domain class

Rename `AbstractMessageProducingHandler` methods: `*reply` -> `*output`

Conflicts:
	src/reference/docbook/whats-new.xml

INT-267: Rework `RoutingSlip` -> `Map<List<String>, Integer>`

Since `RoutingSlip` POJO isn't scalable in the distributed multi-language environment,
it would be better to use some Java generic type for this `ROUTING_SLIP` header.

The `Collections.singletonMap(Collections.unmodifiableList(routingSlipPath), 0)` is the best candidate to be convertible to other systems
and allow to have thread-safety.

The `ROUTING_SLIP` header is recalculated now on each `nextPath`

INT-267: Introduce `RoutingSlipHeaderValueMessageProcessor`

* Rework `HeaderEnricherParserSupport` logic to get rid of SpEL parsing
and change `routingSlipPath` to the `ManagedList<String>` to get gain of `property-placehoder`
* Add `<context:property-placeholder>` stuff to the `RoutingSlipTests`

INT-267: Move inline expressions to the implicit `EERSRS` from the `RoutingSlipHeaderValueMessageProcessor`

INT-267: Fix up JavaDocs and add JDBC test-case

INT-267: Address PR comments

INT-267: Polishing according PR comments

Polishing
INT-3521 `completions` for ChannelInterceptorList

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

INT-3521: Rework invocation `index` to the `Deque` of invoked interceptors

Conflicts:
	src/reference/docbook/whats-new.xml

INT-3521: Address PR comments

Create an `interceptorStack` only if there are `interceptor` on the channel.
Invoke `afterSend(Receive)Completion` only `if (interceptorStack != null)`

Minor Doc Polishing
Update Spring AMQP to 1.4.0.RC1
INT-2426: Add `Idempotent Receiver` EIP pattern

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

Conflicts:
	spring-integration-core/src/main/java/org/springframework/integration/IntegrationMessageHeaderAccessor.java
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