[AMQ-9532] Convert DestinationMapNode from recursion to loops.

[Nikita-Shupletsov]

Because destinations are parsed recursively, it's possible to trigger java.lang.StackOverflowError if a destination has too many nodes.
the PR is converting the recursion to loops.

Ran DestinationMapTest.java to make sure the behavior of the class stays the same. There is no need for additional testing in my opinion, because the behavior is supposed to stay the same as it was before the change.

[cshannon]

This looks like a nice change to me and should certainly improve things if there are a lot of paths.

I looked over everything and I couldn't spot any issues but it's always a little tricky looking at recursive code. I agree that there should be enough tests already. Besides the DestinationMapTest which exercises the map very well, the map is used all over the code base and is extended by the PolicyMap plus others, so I would expect some test failures if there was an issue. I looked at the failures for this PR and it seems like it's just timeout stuff and un-related but it would be nice to see a clean jenkins run.

@mattrpav and @jbonofre , can you take a quick look at this as well and see if you spot anything? We could target it for a 6.1.x release but not sure if we should just keep it for 6.2.0

[mattrpav]

@Nikita-Shupletsov how many is too-many nodes to trigger a stack overflow? What was the -Xss setting when the SO occurred?

[Nikita-Shupletsov]

@Nikita-Shupletsov how many is too-many nodes to trigger a stack overflow? What was the -Xss setting when the SO occurred?

with -Xss256k it's around 1300

i've encountered the issue due to this: https://activemq.apache.org/components/classic/documentation/message-redelivery-and-dlq-handling#setting-expiration-on-messages-in-the-dlq
there were DLQs for DlQs and so on

[Nikita-Shupletsov]

it's 1.5 years old. I assume it's not needed. closing the PR