JIRA: https://jira.spring.io/browse/INT-4245
* Move `ReplyProducingMessageHandlerWrapper` outside of
`ServiceActivatorAnnotationPostProcessor`.
* Use it from the `ServiceActivatorFactoryBean` as well to fix
the missed `Lifecycle` control
* Increase wait timeout in the `ConnectionFactoryTests`
* Mark endpoint as `auto-startup="false"` in the SFTP parser tests
* Remove redundant `org.gradle.daemon=true` from the `gradle.properties`
since it is like that by default for a while already
* Add `ReactiveMessageChannel` implementation based on the provided `Processor<?>` for internal dispatching logic.
Implement the `Publisher<?>` contract to allow downstream `Subscriber<?>`
* Add `ReactiveEndpoint` implementation to deal with the `ReactiveMessageChannel` through the Reactive Streams contract.
* Add appropriate `ReactiveEndpoint` building logic to the `ConsumerEndpointFactoryBean` and `AbstractMethodAnnotationPostProcessor`
* Rework Gateway to use `Publisher<?>` contract instead of `Promise` implementation.
JIRA: https://jira.spring.io/browse/INT-4019
* Add `org.gradle.daemon=true` to `gradle.properties`
* Add `--no-daemon` to CI plans, such as `master` and `nightly`
* Adjust `.travis.yml` to disable `gradlew assamble` task and allow artifacts caching
Add `script` to `.travis.yml` config
Since we have sometimes the problem with cached dependencies and the Travis report doesn't reflect the reality properly,
add `--refresh-dependencies` to avoid such a caching bottleneck
Also add `--parallel` for experiment to see if a new Gradle and Travis can overcome that now
No `--parallel`
Doesn't work forTravis. It indicates the maximum load for CPU as a critical error and interrupts the spawned Gradle Threads
Add `--no-daemon`
This option does not make sense for Travis. It starts a new environment for each build.
Meanwhile looks like `caching` and `--refresh-dependencies` do their premise
