route messages by target system ID and component ID

[Kester-Broatch]

This PR resolves #18

This PR adds some basic routing functionality to the mavp2p tool. I tried my best to follow the standard as defined in - https://mavlink.io/en/guide/routing.html

I apologies for my Go skills, its my first time using Go!

The following rules are iterated over every connected node, every time a message is received:

1. If the message is of type COMMAND_LONG, COMMAND_ACK or COMMAND_INT then, read the target_system and target_component from it and mark the routeMsg variable true. Otherwise broadcast it.

2. if target_system is more than 0 (non-broadcasted) then route it, otherwise broadcast it
   if routeMsg { if targetSystem > 0 { // Route only if it's non-broadcast command

3. if target_system matches the system id of one of the connected nodes then proceed with routing, otherwise discard
   for remoteNode := range nh.remoteNodes { // Iterates through connected nodes
if remoteNode.SystemID == targetSystem {

4. If target_component matches a node or set to broadcast then route, otherwise discard
   if remoteNode.ComponentID == targetComponent || targetComponent < 1 { // Route if compid matches or is a broadcast

5. Does a check that the message is not addressed to itself, if it is then it discards and prints a warning
   if remoteNode.Channel != evt.Channel { // Prevents Loops

6. Finally, if all of these criteria are met then the message is sent to the node
   node.WriteFrameTo(remoteNode.Channel, evt.Frame)

When the cli arg --print-routes is used we can see the behaviour of the routed frames. Eg, here is the interaction of a GCS connecting to a camera video stream using this camera protocol - https://mavlink.io/en/services/camera.html#video_streaming. The COMMAND_LONGS are replied with COMMAND_ACKS etc. (I censored our public IP here)

Known Issues that should be fixed before merging:

• we only check a set of 3 messages if they have a target_system field. I’m not sure right now how to check for every incoming message.
• This routing goes against what @aler9 mentioned about:

some nodes are meant to listen on all incoming traffic for saving telemetry, storing logs, broadcasting telemetry, debugging reasons. So there should be a way to keep the actual behavior on these nodes.

So we'd need to allow for some nodes to be marked as loggers or listeners or whatever...

[aler9]

Hello, i realized that the router already performs some filtering by stopping stream requests messages. Therefore, what i wrote about global loggers is not a current feature, and there are no issues in filtering messages by system ID / component ID and merging this PR. Sorry for the time it took but i had to re-immerse myself into the Mavlink world, since i was away from it for a couple of years.

I added tests and merged this PR, thank you very much.

I'll also add two additional features in the near future:

• if the target node is not found (because the target node has not sent a heartbeat yet), the message will be broadcasted globally
• routing will be extended to all messages with a TargetSystem and TargetComponent field