Predicate message for controllers

[domire8]

The Predicate message interface currently has a field component, so if we want to add controller predicates, we need to change that message definition. At this point, I'm even tempted to break completely and rename the package modulo_interfaces since modulo controllers now include the interfaces as well. This is lower priority though. We can just add two fields controller and hardware to the message without breaking anything..

@eeberhard @bpapaspyros

[bpapaspyros]

renaming the package sounds good to me too, but it is a pretty big change so I leave it up to @eeberhard. As for adding two new fields it also sounds like the simplest non-breaking change, but just to get a bit of discussion rolling:

does it make sense to try to replace component with something more general instead of adding more fields? (I understand this is breaking quite a few things too, so I'm not implying it's a better solution)

[eeberhard]

Changing component to node / node_name would be possible, but it might end up being less efficient.

Right now the component sends its fully qualified node name, rather than the application component name (which it can't necessarily know at runtime).

For the controllers, we have to include the namespace of the hardware so that we can associate the predicate to the right controller (for example, if two otherwise identical "broadcaster" controllers are each running on a separate robot).

The controller can know what hardware it is associated with through a hardware_name parameter that is set through the controller manager. However, the controller plugin node is also namespaced to the hardware accordingly, so using the fully qualified node name of the controller should be equivalent.

The main thing is that we need to be to resolve what component or controller the predicate data refers to, and this is a lookup step that happens very frequently (on every predicate message callback). Rather than having to search first components and then controllers for every matching node name, it would be nice if the individual components and controllers did this work when writing the message, so that parsing the message is faster.

So, I think having (optional) fields for component, controller, and hardware would be the nicest extension.

I also agree that we can make the package name more generic as modulo_interfaces. But, we can work with the existing package name for now and refactor this later.

[domire8]

As agreed in person, we will start to action this by adding a modulo_interfaces package in addition to the existing packages to start the refactor without breaking modulo right away and then later remove modulo_component_interfaces