fix consumers dlq configuration

[riccardomodanese]

Brief description of the PR.
This pr cleans the Camel routes configuration (some old configuration was still present) and reorganizes dlq queues name
Introduces the $SYS prefix for internal use. This prefix is used for dlq and further internal feature and is not meant to be subscribed by external devices.

Related Issue
none

Description of the solution adopted
none

Screenshots
none

Any side note on the changes made
none, the effect of the changes is bound to internal components.
NO BACKPORT

[codecov]

Codecov Report

Merging #3890 (9bc5860) into develop (4924fd7) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

❗ Current head 9bc5860 differs from pull request most recent head b60d8b7. Consider uploading reports for the commit b60d8b7 to get more accurate results

@@              Coverage Diff              @@
##             develop    #3890      +/-   ##
=============================================
- Coverage      20.55%   20.54%   -0.01%     
  Complexity         6        6              
=============================================
  Files           1940     1940              
  Lines          41540    41543       +3     
  Branches        3939     3940       +1     
=============================================
- Hits            8537     8534       -3     
- Misses         32606    32612       +6     
  Partials         397      397              

Files	Coverage Δ
...ice/camel/listener/error/ErrorMessageListener.java	0.00% <ø> (ø)
...ua/client/security/ServiceClientMessagingImpl.java	0.00% <0.00%> (ø)
...se/kapua/commons/event/jms/JMSServiceEventBus.java	17.33% <0.00%> (ø)
...a/broker/artemis/plugin/security/ServerPlugin.java	0.00% <0.00%> (ø)

... and 1 file with indirect coverage changes

[dseurotech]

Missing $SYS/ prefix, is that right?

[riccardomodanese]

not forgotten, it's the service broker used for authentication so for now I preferred to leave the queues without prefixes.
Do you suggest to use the prefix here (service broker) also? (in the event broker I prefer to leave namespace as it is now)

[elbert3]

To me it doesn't seem like a bad idea to use this separate namespace for internal messages, though I realize it's for a separate broker and adds a little overhead. Otherwise I think the PR is fine and will go ahead and approve.

[riccardomodanese]

To be honest I'm not sure about which is the best solution. I mean, the telemetry broker handles both external load (messages from clients and Camel consumers) and internal (like the dlq for example)
On the other side the event and service brokers handle only internal load now (events are meant to be used only by internal components now and the authentication service is performed by a service consumer built for this scope).
Anyway having services and events deployed in the same broker could lead to a namespace conflicts.

[riccardomodanese]

I think what you are suggesting worth to be implemented now.
I'm proposing a refactoring like this one (I'm going to implement it in a new commit)

Telemetry broker (only dlq):
$SYS/dlq/default
$SYS/dlq/expired

Event-broker:
$SYS/svc/evt/EVENT_ADDRESS

Service-broker:
$SYS/svc/ath/req
$SYS/svc/ath/resp/brokerId

Event/Service-broker dlq:
$SYS/svc/dlq/default
$SYS/svc/dlq/expired

I think it's a good proposal but I'm looking forward for your feedback!

[elbert3]

I agree that this separate namespace should help avoid conflicts and provide more flexibility with how components are deployed. I think it would also be helpful to consider now how it should be structured/used. For the telemetry dlq for example, should it also specify the service/consumer - i.e. "$SYS/telemetry/dlq/default", etc.?

[riccardomodanese]

I preferred to use MSG so the new addresses (last commit) are:

Telemetry broker
$SYS/MSG/dlq/default
$SYS/MSG/dlq/expired

Event-broker
$SYS/EVT/EVENT_ADDRESS

Service-broker
$SYS/SVC/auth/req
$SYS/SVC/auth/resp/brokerId

$SYS/SVC/dlq/default
$SYS/SVC/dlq/expired

I moved event prefix out of svc.
What do you think?

[elbert3]

Works for me!