Rolling pr duplicated nodes names

[SamueleSandrini]

Hi @fmrico,

while I am doing some tests I noticed an issue we had some time ago with multi-robot experiments related to the node name duplication issue described in #381, particularly affecting domain_expert_client and problem_expert_client.
In this pull request, I propose an approach to avoid the situation where multiple nodes have the same name.

Problem

When client nodes are instantiated as class attributes, they inherit global arguments and end up sharing the same node name as the parent node. This leads to multiple nodes with identical names in the ROS graph, which can cause unexpected behavior.

Proposed solution

This PR introduces two changes:

1. Disable global arguments for internal nodes
   Both C++ and Python client implementations now explicitly disable global arguments when creating internal nodes, preventing unintended name reuse.

2. Explicit naming for client nodes
   Added constructors that allow specifying node names.
   Internal client nodes are now named using the pattern: {external_node_name}_{internal_node_name}. Let me know if this approach works for you, or if you would prefer {internal_node_name}_{external_node_name} to group all domain_expert_client / problem_expert_client nodes. I am also open to exploring alternative approaches if you think there are better ways to avoid this proliferation of duplicate nodes. I was also thinking about whether it might be a good idea to mark them as hidden nodes by using an underscore as a node name prefix, as they might be more confusing than helpful (view all domain/problem_expert_client nodes), let me know what you think.
   This ensures uniqueness and improves graph readability.

Example result:

• No duplicated node names
• Clear association between external node and its internal clients

Additional changes

• Python parser: ignore comments inside PDDL expressions to avoid parsing issues
• a minor adjustment in the use of ament_index_cpp::get_package_share_directory in ComputeBT and ExecutorNode to improve cross-compatibility between ROS versions (verified with Jazzy). I removed this changes, as I noticed I re-introduces the warnings that was already addressed in Deprecated functions (warnings) #397 (comment). Nevertheless, that is the only aspect that makes the rolling release incompatible with Jazzy. What do you think about introducing a utility/wrapper function to make it cross-compatible?

Thanks!

[fmrico]

Hi @SamueleSandrini

Thanks for detecting this and the work made here.

I'm hesitant to expose the internal node name as an argument in the client constructor. I believe this creates unnecessary coupling, as it's confusing for the user to understand that it's for the name of an auxiliary internal node we're creating. This unnecessarily increases unwanted coupling. I'd prefer not to expose it and instead create random node names. For example, all the nodes that create the problem_clients could start with the same name, but then have a random component, like "problem_client_askfljs" or something similar. What do you think?