Update MessageListener reference documentation.

Original Pull Request: #2052

src/main/asciidoc/new-features.adoc

@@ -3,6 +3,11 @@
 
 This section briefly covers items that are new and noteworthy in the latest releases.
 
+[[new-in-2.6.0]]
+== New in Spring Data Redis 2.6
+
+* Support for `SubscriptionListener` when using `MessageListener` for subscription confirmation callbacks. `ReactiveRedisMessageListenerContainer` and `ReactiveRedisOperations` provide `receiveLater(…)` and `listenToLater(…)` methods to await until Redis acknowledges the subscription.
+
 [[new-in-2.5.0]]
 == New in Spring Data Redis 2.5
 

src/main/asciidoc/reference/reactive-messaging.adoc

@@ -57,6 +57,21 @@ ReactiveRedisMessageListenerContainer container = new ReactiveRedisMessageListen
 Flux<ChannelMessage<String, String>> stream = container.receive(ChannelTopic.of("my-channel"));
 ----
 
+To await and ensure proper subscription, you can use the `receiveLater` method that returns a `Mono<Flux<ChannelMessage>>`.
+The resulting `Mono` completes with an inner publisher as a result of completing the subscription to the given topics. By intercepting `onNext` signals, you can synchronize server-side subscriptions.
+
+[source,java]
+----
+ReactiveRedisConnectionFactory factory = …
+ReactiveRedisMessageListenerContainer container = new ReactiveRedisMessageListenerContainer(factory);
+
+Mono<Flux<ChannelMessage<String, String>>> stream = container.receiveLater(ChannelTopic.of("my-channel"));
+
+stream.doOnNext(inner -> // notification hook when Redis subscriptions are synchronized with the server)
+    .flatMapMany(Function.identity())
+    .…;
+----
+
 [[redis:reactive:pubsub:subscribe:template]]
 === Subscribing via template API
 

src/main/asciidoc/reference/redis-messaging.adoc

@@ -47,6 +47,8 @@ Due to its blocking nature, low-level subscription is not attractive, as it requ
 
 `RedisMessageListenerContainer` acts as a message listener container. It is used to receive messages from a Redis channel and drive the `MessageListener` instances that are injected into it. The listener container is responsible for all threading of message reception and dispatches into the listener for processing. A message listener container is the intermediary between an MDP and a messaging provider and takes care of registering to receive messages, resource acquisition and release, exception conversion, and the like. This lets you as an application developer write the (possibly complex) business logic associated with receiving a message (and reacting to it) and delegates boilerplate Redis infrastructure concerns to the framework.
 
+ A `MessageListener` can additionally implement `SubscriptionListener` to receive notifications upon subscription/unsubscribe confirmation. Listening to subscription notifications can be useful when synchronizing invocations.
+
 Furthermore, to minimize the application footprint, `RedisMessageListenerContainer` lets one connection and one thread be shared by multiple listeners even though they do not share a subscription. Thus, no matter how many listeners or channels an application tracks, the runtime cost remains the same throughout its lifetime. Moreover, the container allows runtime configuration changes so that you can add or remove listeners while an application is running without the need for a restart. Additionally, the container uses a lazy subscription approach, using a `RedisConnection` only when needed. If all the listeners are unsubscribed, cleanup is automatically performed, and the thread is released.
 
 To help with the asynchronous nature of messages, the container requires a `java.util.concurrent.Executor` (or Spring's `TaskExecutor`) for dispatching the messages. Depending on the load, the number of listeners, or the runtime environment, you should change or tweak the executor to better serve your needs. In particular, in managed environments (such as app servers), it is  highly recommended to pick a proper `TaskExecutor` to take advantage of its runtime.