INT-3325 Add Redis Channel Message Group Store

[garyrussell]

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

Optimized MGS for QueueChannel - uses a LIST for
each channel and LPUSH, RPOP.

• Also fix MutableMessage to be Serializable

[artembilan]

Seems for me like we should introduce new marker interface ChannelMessageStore and protect QueueChannel with that and disallow to use other out of the box implementations.
WDYT?

Otherwise, of course, LGTM

[garyrussell]

Good idea - and maybe a sub-interface PriorityChannelMessageStore which would be the required type if we open up message-store on priority-channel (and you'd get a QueueChannel with a PriorityChannelMessageStore instead of a PriorityChannel).

I think disallowing general message stores might be a little too much; some use cases might be just fine and it would be a burden for us to force them to maintain 2 sets of, say, JDBC tables. Maybe we could just emit a WARN for now if they don't use an optimized store (or just leave it to the documentation).

I will rework this PR on Monday.

[garyrussell]

Added marker interfaces, priority store.

Rebased, squashed, pushed.

[artembilan]

, ChannelMessageStore

[artembilan]

BasicMessageGroupStore is redundant

[artembilan]

No polishing yet, but the main purpose to coerce like this RedisChannelMessageStore:

private final RedisTemplate<Object, Message<?>> redisTemplate;

And I see that here is a confuse around this.getBeanName() + ":".
I understand the purpose of it - the region to allow to use several MS on the same Redis: 👍
But we should be carefull how we do it: in some place you use it, but in others don't: just provide the full groupId from test, but I'm not sure that QueueChannel on addMessageToGroup provide the region too.

[artembilan]

Onother thought.
May we anyway to encapsulate all option within the single MS implementation and allow to end-user to use it from any message-store option? And determine which type of operation to perform at runtime, e.g. via some ThreadLocal variable. Of course here we have to be carefull around this.getBeanName() + ":*" for managed operation. However we can't provide ThreadLocal from JMX to separate the operation for queue and for priority-queue. Although we have the same for JDBC (region and several channels) and it doesn't cause any confuse.

[artembilan]

Redundant

[garyrussell]

May we anyway to encapsulate all option within the single MS implementation...

I prefer to keep separate implementations - you will see that every "business" method from the superclass is overridden; they just share infrastructure methods. That means we'd have an if test in every method, raising the complexity. It seems cleaner to me to keep them separate - also, it makes it easier to do the assertions in MGQ.

[artembilan]

OK. Nevermind: canceled the encapsulation question.
Let's go ahead with other concerns here!

[garyrussell]

Pushed

[artembilan]

LGTM
Merging with simple red JavaDocs and some typos in Docs

[artembilan]

Merged