ARTEMIS-5153 Mark federation events and control queues as internal

[tabish121]

In order to better indicate their nature as broker feature specific queues we can mark the temporary queues created for AMQP federation events and control link messages as internal.

[tabish121]

I've run the full test suite on this without any new failures

[clebertsuconic]

@tabish121 I'm puzzled to this check style.. I can't reproduce it locally.. and my test suite also worked fine.

Same thing on my PR I just sent.

[brusdev]

Those failure are false positive, the checks passed on my fork, see https://github.com/brusdev/activemq-artemis/actions/runs/11833280900

[gemmellr]

Its not a false positive...but the issue isnt in the PR changes, the issue was on main, so the PR run failed but a run of the source branch (which lacked the problem commit) wouldnt.

Caused by #5338 being merged despite the check jobs failing. Should hopefully be fixed by 8d02f8d

[gemmellr]

I rebased the PR, bringing the problem and fix commits into the source branch, and triggering a fresh fully-up-to-date PR run which passed the checks.

[clebertsuconic]

so weird how the checkstyle was not working for me locally.

as for the PR I merged.. I had one previous build where it passed and I had only done a simple merge.

Sorry for the hassle and thanks for fixing it.

[gemmellr]

Probably not that weird.

This PR, and your PR, didnt have the problem commit on the source branches, so their jobs would work in the fork repos, and the build would work locally. You merged the other/earlier PR which broke main, just before these 2 PRs were raised/updated 1-commit-from-head. When the new PRs were raised they ran on the merge result against the main base branch, so those runs can then give a different result than local/fork runs when the source branches arent based at the head of main at the point the PRs are raised.

I also upgraded Checkstyle a couple of days ago, so seems like there was perhaps also a change in its behavior inbetween your different runs on the problem PR spanning that update, which you would presumably have also brought in when rebasing and pushing.

Basically doubly bad timing, and good example of 'just a simple rebase' still often needing at least a re-build if not re-test.