Feature request

Feature description

In order to bundle reusable logic bits within rcl to support actions, basic access to action ID information on a per message basis is a prerequisite. And since rcl cannot treat client library specific messages as anything but pointers void of any type, some low-level C access to that information has to be generated and exposed.

Implementation considerations

A potential solution (as suggested initially by @jacobperron) would be to generate conversion functions for the relevant message types. Elaborating on this idea, I believe we could introduce getters and setters in rosidl_action_type_support_t to help rcl interact with type erased messages. Generated function count totalizes 10 functions, including:

1. GoalInfo getters from:
   1. action goal request messages, for the action server to use.
   2. action goal response messages, for the action client to return.
   3. action result request messages, for the action server to use.
   4. action result response messages, for the action client to return
   5. action feedback messages, for the action client to filter and return.
2. GoalInfo setters into:
   1. action goal request messages, for the action client to set and track.
   2. action goal response messages, for the action server to set.
   3. action result request messages, for the action client to set.
   4. action result response messages, for the action server to set.
   5. action feedback messages, for the action server to set.

To this, we add 6 more functions to deal with cancellation and status updates (that use the same types for all actions):

1. GoalInfo setter into action cancel request messages, for the action client to use.
2. GoalInfo getter from action cancel request messages, for the action client to set.
3. GoalInfoArray setter into action cancel response messages, for the action server to set.
4. GoalInfoArray getter from action cancel response messages, for the action client to track.
5. GoalStatusArray setter into action status messages, for the action server to use.
6. GoalStatusArray getter from action status messages, for the action client to filter and track.

Allocation mechanism for these messages in a type agnostic manner may also be necessary.

This scheme allows us to push most if not all action client and server logic inside rcl, avoiding duplication in client libraries, while making use of client library specific types to ease introspection and further tinkering. We may also strip some of them and delegate on the client library, tolerating duplication to an extent.