ARTEMIS-6164 MQTT retained message support for mirror and federation

[gtully]

Ensure MQTT retained messages are propagated to peer brokers via mirror
and federation so that new subscribers on any broker receive the correct
retained state.

Centralise MQTT retain handling into MQTTRetainMessagePlugin, a broker
message plugin registered by the MQTT protocol manager factory. The
plugin fires via afterMessageRoute on every routing path: normal MQTT
publish, mirror, federation, and AMQP bridge.

MQTTRetainMessageManager is simplified to only the
subscriber-side addRetainedMessagesToQueue().

[tabish121]

I'm not particularly keen on this solution as it scatters the handling out amongst components that don't necessary have any business knowing about MQTT or retained messages at all. I'd guess you asked the AI to solve this scenario of mirror and federation but it sort of gives away the problem in that it totally misses that this also applies to AMQP bridge from address receivers when the remote is an Artemis server forwarding you MQTT retained messages so you'd likely want similar handling. Placing calls like this handler method out in the weeds of the broker code makes for a brittle solution. I think you should focus on handling this closer in the core routing code where components like AMQP don't have to selectively decide what MQTT features they need to handle as that is certain to lead to an ever large mess as you add more and more special cases.

[gtully]

fair comment, I was thinking of a plugin or interceptor that the mqtt protocol handler could add to deal with the publish side of retain via process route. That would be more implicit and contained. I was discounting the use of a bridge, but of course it could be relevant in some hub/spoke scenarios or one way scenarios. For the "publish every where - partition" usecase it needs to be symmetric. Thanks for the feedback.