DroneCAN: support sending/receiving DroneCAN messages in lua

[tridge]

This adds support for sending and receiving DroneCAN messages from lua scripts.

It includes an example script that subscribes to messages, sends requests and sends broadcast messages

Note that I have not done a lua compiler for DSDL, so manual message parsing is needed

This PR relies on this libcanard PR: dronecan/libcanard#74
and this DSDL update: dronecan/DSDL#67

Due to the simplification of libcanard this PR also saves about 4k of flash

should I move the GlobalTime broadcast to C++? Depends if other devices could use it

[tpwrules]

I have to admit I don't understand what getting the internal libcanard semaphore accomplishes. Is it just to avoid deadlocks? I don't think that can happen here.

[tpwrules]

the reason we need the get_semaphore() is mutex ordering. If we don't et that mutex before we get the sem in the scripting code then we deadlock if a message arrives during deletion of a Subscriber in DroneCAN_Handle::check_message(). It happens in SITL if you comment out the get_semaphore() code, DroneCAN thread is in handle_message(), scripting in check_message()

Ah yes, I see that now. But why don't we just release h->sem before the delete? The function which sets up h->subscriber does not even take h->sem. It also runs on the same thread as the function doing the delete so I don't think there is a race condition. If we received a message it would just get stored before being thrown away in the destructor.

This also applies to the destroy_all method, I don't see the danger in letting handlers continue to execute while the subscribers are destroyed. The canard lock will protect things.

[tridge]

@tpwrules I've removed the libcanard get_semaphore() and the per-handle semaphore, replacing it with get_sem_rx() in AP_DroneCAN

[tpwrules]

Happy to see the semaphores cleaned up. I think the per-handler semaphore would have worked fine, but using the DroneCAN one probably saves memory (at the cost of CPU and interference risk).

I definitely would want to see the battery tag changes pulled out in a separate PR.

[tridge]

@tpwrules i've moved the BatteryTag changes into #29983

[IamPete1]

Scripting stuff looks good, just a small thing in the docs.

[tpwrules]

Some error condition handling but overall looks good.

[tpwrules]

The little test example works well on Cube Orange. Great work! I also did some futzing with the REPL and could not immediately break the autopilot or my node.

Future expansion ideas:

• Autotest
• Ability to have autopilot itself/other scripts see script-sent messages
• DroneCAN server support (your idea)
• Priority handler/inhibit mechanism so a script can eat messages
• C++-assisted encoding and decoding

[tridge]

@tpwrules thanks for your help with this PR!