Add widget API

[Williangalvani]

No description provided.

[Williangalvani]

I think we should not use the cockpit version here. thoughts?

[rafaellehmkuhl]

We shouldn't. Cockpit has new releases every week, while the API will probably be updated every few months.

[rafaellehmkuhl]

I have put some comments here and there, but in general I really like the solution and loved that you added support for Ardupilot variables in the data-lake!

[ES-Alexander]

This is presumably out of scope for this PR, but would this Cockpit API be the basis for supporting widgets registering their own Actions (per #609) in future? :-)

[rafaellehmkuhl]

This is presumably out of scope for this PR, but would this Cockpit API be the basis for supporting widgets registering their own Actions (per #609) in future? :-)

Yes, the idea is to put their metadata in the same json.

[Williangalvani]

This is presumably out of scope for this PR, but would this Cockpit API be the basis for supporting widgets registering their own Actions (per #609) in future? :-)

Yes, the idea is to put their metadata in the same json.

And to allow doing it programatically as we extend the API

[rafaellehmkuhl]

Should we keep this? I feel like it creates an incentive for people not to explicitly register their variables.

With the idea of also adding unit information to the variables, this will become more and more of a problem.

[Williangalvani]

I can make it happen only in ardupilot.ts for the mavlink data. I assume we don't want to register all mavlink data manually

[rafaellehmkuhl]

Agree, but in this case, to enforce the interface and so we can improve it in the future without having to change a lot of places in the code, I think it would be better to put this "type inferring" in the variable registration and register explicitly in the ardupilot file, even if without the type. It would just be this if clause, but in the ardupilot file instead of the data-lake itself. What do you think?