fix(activemq-client:6.0.0): resolve test failures

[erguiti-imane]

What does this PR do?

• Removed reliance on the legacy javax.jms API and use jakarta.jms instead
• Regenerate GraalVM metadata for activemq-client 6.0.0

Checklist before merging

• I have considered including reachability metadata directly in the library or the framework (see our contributing document)
• I am the original author of all content provided in the pull request, and I did not copy the content from any other source (see the tests section from our contributing document)
• For all tests where I am not the sole author, I have added a comment that proves I may publish them under the specified license (see the tests section from our contributing document)
• I have properly formatted metadata files (see our formatting guide)
• I have added thorough tests (see the tests section from our contributing document)
• I have filled all places where my pull request accesses files, network, docker, or any other external service (see the section above)

[dnestoro]

@msupic please review this pull request when possible as we are planning to have a new release of reachability metadata (+Native Build Tools) soon.

[msupic]

After I reformatted the content of new json metadata files from 6.0.0 and compared with json metadata files from 5.18.1, I found that only difference between those files is in one entry from the reflect-config.json file:

  {
    "condition": {
      "typeReachable": "org.apache.activemq.util.LongSequenceGenerator"
    },
    "name": "org.apache.activemq.util.LongSequenceGenerator",
    "fields": [
      {
        "name": "lastSequenceId"
      }
    ]
  }

@erguiti-imane - could you please confirm that? If that is the case, I think that instead of recreating all metadata for 6.0.0, we can have a simple PR which adds above mentioned entry to the reflect-config.json file 5.18.1

[erguiti-imane]

I had to make some changes to the tests by removing the reliance on the legacy javax.jms API and replacing it with jakarta.jms, which is why I generated new metadata. As we previously agreed, whenever a library starts breaking, we create a new directory and use it for all subsequent versions until another breaking change occurs. This approach helps keep things organized. What do you think, @dnestoro ?

[dnestoro]

I had to make some changes to the tests by removing the reliance on the legacy javax.jms API and replacing it with jakarta.jms, which is why I generated new metadata. As we previously agreed, whenever a library starts breaking, we create a new directory and use it for all subsequent versions until another breaking change occurs. This approach helps keep things organized. What do you think, @dnestoro ?

@erguiti-imane if you changed tests compared to the previous supported version, add another entry (directory for tests and metadata) as we agreed. Only when we have same tests (and you just regenerates metadata), you may just update metadata

[erguiti-imane]

I made the changes to the test class specifically for version 6.0.0, where jakarta.jms is expected. However, for older versions like 5.18.1, ActiveMQ is still based on javax.jms (Java EE 8 / legacy APIs). I tested to confirm, and the changes broke tests for older version.
To maintain compatibility, we need to keep using javax.* for older versions and only use jakarta.* starting from 6.0.0. Hence why separation would be a necessity.

[dnestoro]

@msupic can you please review this pull request and add comments if something needs to be changed? If there is no issues remain, we should proceed with merging this PR.