[DO NOT MERGE YET] INT-4186: Add @Reactive to Messaging Annotations

[artembilan]

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

Just a PoC how it would look from the end-user perspective

• Add @ChannelListener which is fully analogue of similar solution in other places - @RabbitListener, @KafkaListener, @JmsListener.
  In other words it has ability to subscriber to several destinations providing common options for target endpoints
  The reply will be processed via @SendTo or replyChannel header.
  This functionality is fully similar to the @StreamListener
• Add @Reactive annotations' option alongside with @Poller to allow to use ReactiveConsumer underneath with provided backpressure strategy

/CC @garyrussell , @mbogoevici , @smaldini

[artembilan]

After merging all the InvocableHandlerMethod efforts I don't see reason in this @ChannelListener feature.
The @ServiceActivator can simply cover the functionality.

Looks like we just need to introduce something like "Content-Type negotiation" for existing Messaging Annotations and that's all.

What am I missing?
Thanks

[artembilan]

But @Reactive addition is still on its way.
I'm not going to abandon it 😄

[garyrussell]

I don't have any issues with that approach; I originally thought adding content conversion to @SA was what we would do - but we also need to add error handler support (like we now have with @RabbitListener).

[artembilan]

Re. content conversion.
Right now we can inject MessageConverter to the AbstractMessageChannel.
Looks like similar approach is applied for the @StreamLisntener:

MessageConverterConfigurer.ContentTypeConvertingInterceptor

Both of them has the same flaw: per channel.

Would be much better to keep content negotiation really close to the @ServiceActivator method.
And maybe just introduce one more attribute:

/**
 * The consumable media types of the mapped request, narrowing the primary mapping.
 * <p>The format is a single media type or a sequence of media types,
 * with a request only mapped if the {@code Content-Type} matches one of these media types.
 */
String[] consumes() default {};

And really build particular MessageConverter for the target InvocableHandlerMethod only, independently of the other message channel subscribers. Although this must covers SpEL somehow as well...

I don't follow with the "error handler support" discussion. This is something isn't applied for SI.
We always propagate exception in case on SubscribableChannel and perform errorChannel in case of PollableChannel (@Poller):

/**
 * @return The the bean name of default error channel
 * for the underlying {@code MessagePublishingErrorHandler}.
 * @since 4.3.3
 */
String errorChannel() default "";

The @Reactive can have errorChannel() as well.

WDYT?

[artembilan]

Remove @ChannelListener from the PoC since all its requirements are already covered with regular method invocation mechanism.
This PR represents only @Reactive option idea for the Messaging Annotations.
How to use it from the end-user perspective.
The framework will create a ReactiveConsumer for these options and adapt the inputChannel to the Reactive Publisher.
In the future we move such a feature to the <reactive> sub-element in the XML support as well.

I won't mind any other ideas.
Thanks

[artembilan]

Closed in favor of #3503