Fix system discovery

[JonasVautherin]

Without this fix, MAVSDK has issues detecting more than one system (it seems like one notify_on_discover is lost, because one of the systems was always_connected and is renamed when a new one is detected).

This fix just clears the "fake system" when a new one is discovered, so that the new one triggers the discovery callback.

[julianoes]

This should be ok, however, in the future we should not even require any of this anymore as you can send out heartbeats to a remote port just from a MAVSDK server component without having to have a system as such.

[JonasVautherin]

Right, but what about client components that want to initiate the discovery? Are you saying that the client components should always listen and the server components should always broadcast?

[julianoes]

Presumably 🤔, but I'm sure you will find examples where that does not hold.

[JonasVautherin]

It's just that I can imagine a system where the drone listens on some port, and the client connects to it. Somehow I actually believe that the client should always initiate the connection (opposite to what all mavlink implementations I've seen do, I know 😅 ). The drone could send a discovery heartbeat that the client would pickup, and then the client would initiate the connection. In other words, it would separate the discovery and the actual connection.

Right now it is possible on the MAVSDK side, since the client can connect with udp://<drone_address>:<port>. And I think we should try to keep that.

One consequence of splitting discovery and connection is that the System objects would not need the Mavsdk parent anymore. Right now there is only one UDP connection shared between multiple systems, living in Mavsdk, and therefore the System objects need it. But if the System objects were the ones initiating the connection (i.e. Mavsdk discovers systems on port 14550, then for each creates a System(drone_address, drone_port), and the System initiates the connection), then each System would handle its own socket and be truly separate from Mavsdk, which would be here only for discovery.

Or something like that 😅.

[julianoes]

For what it's worth: I'm all for separating discovery and connection, best with backwards compatibility.

Yer something like that might work indeed. There are however a couple more dependencies from systems to mavsdk that would have to moved as well (e.g. timeout or call every handlers).