Current mavlink architecture, possible custom mavlink, etc

[Davidsastresas]

I saw now since the cmake change, we are managing mavlink differently, and we are really no longer using the mavlink submodule, as everything is done fetching directly to a particular repo and commit in CMakeLists.txt from the MAVLink folder. I don't think this is necessarily bad but:

• Should we remove the mavlink submodule then?
• How would be the most efficient way now to test custom mavlink locally? Of course for something that is already in a repo it is straightforward, but do we have any mechanism to quickly override this on a custom build, or even in a non custom build, just to test mavlink changes locally?

The workflow I used to follow was to just update the corresponding .xml and calling mavgenerate.py. Is there an alternative approach similar to this that I am missing?

Pinging @HTRamsey as I think you were the one managing this change, and also @julianoes as I think you probably work eventually with custom mavlink, so you might like to be aware.

Thanks!

[HTRamsey]

This is something I've needed to do for a custom build, so I'll try and get to it soon. Should be simple. In regards to the submodule, I'm not entirely sure yet. Apparently some build methods don't have internet accessible (like making a flatpak) so I have left the submodules alone and just moved them all to the libs folder for now