Refactored pprzlink python Ivy link interface to improve error reporting

[MJafarMashhadi]

xref #116

Changes:

• restructured some if statements to reduce nesting and imrprove readability
• Errors regarding the program being in the wrong state (e.g. trying to send message before starting the Ivy link) or invalid inputs to functions now raise exceptions instead of returning None. It's just a best-practices in Python that gives the library user more options for handling errors.
• improved/updated doc strings

---

This changes the class's interface (send and send_raw_datalink methods' to be more specific) and could become backwards-incompatible. I cross-checked usages of IvyMessagesInterface with the main repository, including the submoduled projects. Most of them were only subscribing to certain messages and weren't using these methods. The ones which sent messages were not sending telemetry messages that can in an special case raise ValueError. To best of my knowledge, this is safe to merge, but it never hurts to have a second pair of more experienced eyes review it.

[gautierhattenberger]

I think this is a good option to raise exceptions. however, I think there are a few other places where it should be catch properly, not only in ivy.py. serial.py, udp.py and message.py are also using messages_xml_map. What do you think ?

[MJafarMashhadi]

Hi, thanks for you comment!

Here I handled the exception because the source of the error is outside the program, it happens when receives an unknown message and just ignores it which is robust and fine. There is a piece of code in pprz_transport that does the same thing and I missed. I'll fix that in a few hours.

In other parts, the messages_xml_map usages were either safe (e.g. calling parse_messageswhich doesn't raise any exceptions) or with valid parameters (e.g. constants in tests or values that are already checked).

The last case is in the PprzMessaage constructor which gets the inputs as parameters from the user. If the parameters are invalid it's the user's responsibility to handle the error, so I didn't add any error handling there.

[MJafarMashhadi]

There is a piece of code in pprz_transport that does the same thing and I missed. I'll fix that in a few hours.

I'm done now. Please review the new changes. Thanks!

[MJafarMashhadi]

As long as they are not sending telemetry messages (which I couldn't find any) they should be fine, but if there were any bug reports just mention me I'd be more than happy to fix 😅

-- send_raw_datalink is used in:

• guided_mode_example.py which sends a couple of valid datalink messages
• gb2ivy.py the same, it sends a valid dl message
• rtp_viewer.py also sends dl message

send is used in:

• guided_mode_example.py it sends valid ground messages as well as an AIRCRAFTS_REQ which can be replaced with send_request when #122 is merged
• gb2ivy.py what it sends are all safe dl messages
• crazyradio2ivy.py it could use a try...except to be safer
• circularFormation.py which is safe, sending DL_SETTINGS messages
• dcfInitTables.py is also okay
• matlab2pprz.py This is safe too
• move_waypoint_example.py nice and safe
• ctcStartSync.py and ctcInitTables.py are good too
• fc_rotor.py sending dl message, safe
• natnet2ivy.py Sending ground and dl messages, safe
• opensky.py ground message, it's safe
• udp_link.py forwards messages from a UDP channel to an IVY one. Troublesome messages are already dropped in the UDP receive side (caa1337)
• pprzlink_proxy.py The same, forwards messages from a channel to another one, the messages are sanitized on the receiving side
• mesonh.py Sending ground message, safe

That's all

[gautierhattenberger]

thanks for the detailed review!

[MJafarMashhadi]

Thank you!