Refactor MAVLinkParameters into client and server classes

[julianoes]

This splits the MAVLinkParameters class into MavlinkParameterClient and MavlinkParameterServer.

This brings:

• Support to provide parameters in components.
• Get/set parameters for a specific component.
• Both with normal as well as extendended parameters.

Big thanks to @Consti10 for starting this work!

[julianoes]

The current state is that it compiles again and the tests seem to pass but now it needs simplifying and cleanup.

[JonasVautherin]

Wow that's a big one, with quite some improvements! It depends on mavlink/MAVSDK-Proto#296, right?

Just a couple questions:

1. Is that right that it is the responsibility of the drone to now have conflicting param names between components? It seems to me that we save them all together, so if a camera has a param called MODE and the autopilot also has it, then they will conflict. Correct?
2. What happens when select_component is called? Does that impact the params already in the queue, or only the new ones? Say I select the autopilot, set a param (which puts it on the worker queue), then select the camera to set another param. Am I guaranteed that the first param will be sent to the autopilot?

[julianoes]

@JonasVautherin thanks for the review!

1. Is that right that it is the responsibility of the drone to now have conflicting param names between components? It seems to me that we save them all together, so if a camera has a param called MODE and the autopilot also has it, then they will conflict. Correct?

That's a good point I haven't thought about. Sounds like I ought to change it.

Edit: I had a look and the client is per target component ID, so it has separate caches and it should not conflict if I have that right.

2. What happens when select_component is called? Does that impact the params already in the queue, or only the new ones? Say I select the autopilot, set a param (which puts it on the worker queue), then select the camera to set another param. Am I guaranteed that the first param will be sent to the autopilot?

Good point. I need to check again what I did but better would definitely be if it only affects the new ones. I'll see if I can change it.

Edit: yes, that's indeed how it works already. There are queues for all components in system_impl and when selecting the component, the next request will just go on another cache and queue instance.