#35 topic wildcard handling

[GreenRover]

Issue #3: Replace wildcards from topic name to _ in queue name

[Nephery]

Thanks @GreenRover. I'll take a deeper look at this next year to consider for the upcoming 2.0.0 release. But here are my initial thoughts:

Issue 2: Enable to have variables in topic name.

I think this a neat idea. My only concern about this, is that if somebody actually wanted a subscription called sensor/temperature/<station>. Then it wouldn't work since <station> would be detected as a variable instead of a plain string.

Instead, to resolve this conflict, this should be a configurable feature which the user can decide to use or not use. e.g. create a boolean producer/consumer binding config option named something along the lines of useDestinationWildcardVariables. Not entirely sure if this feature should be enabled or disabled by default.

Will get a header "destination_station" == "bern"

Instead of creating a different header for each variable, It might be cleaner to create a single header called something like destinationVariables or destinationWildcards and have it be of type Map<String,String> where an entry's key is the variable name (station in this case) and its value is the variable value (bern in this case).

---

@Mrc0113 could I also get your thoughts on this when you're back next year?

[GreenRover]

is not a valid part of a subscription. I choosed the <> because > is a solace wildcard

[Nephery]

A > that appears anywhere else other than by itself at the last level of a subscription topic in the string is treated as the > character rather than a wildcard.

https://docs.solace.com/PubSub-Basics/Wildcard-Charaters-Topic-Subs.htm

So in this particular case, the > in sensor/temperature/<station> would be treated as a literal character.

[GreenRover]

Instead of creating a different header for each variable, It might be cleaner to create a single header called something like destinationVariables or destinationWildcards and have it be of type Map<String,String> where an entry's key is the variable name (station in this case) and its value is the variable value (bern in this case).

I changed it to: "destinationVariables"

[GreenRover]

Rebased to: "#37" waiting for it to be merged.

[Nephery]

@GreenRover could you split issue 2 into a separate PRs?

[GreenRover]

@Nephery This pr only contains_ enable the destination to be able to contain wild cards.
And topic variables was moved to #45

[Nephery]

Needs tests to ensure that everything that depends on queue names works with the substitution:

• Basic consumer group functionality
• Producer-side consumer group pre-provisioning (i.e. requiredGroups)
• Additional topic subscriptions (i.e. queueAdditionalSubscriptions)
• Error queue republishing

Also I suggest rebasing your changes onto the squashed commit in stage-2.0.0 (#37 has been merged):
git rebase --onto stage-2.0.0 HEAD~<commit_count>

[GreenRover]

• rebased to stage-2.0.0 done
• Test: "Basic consumer group functionality" manually done
• Test: "Producer-side consumer group pre-provisioning" i dont understand what "requiredGroups" is
• Test: "Additional topic subscriptions" manually done
• Test: "Error queue republishing" manually done