replace pyro with varlink or gRPC

[chombourger]

While the switch from ZeroRPC to Pyro was relatively easy, the Debian bookworm to trixie migration revealed a protocol breakage as we were forced to switch from Pyro4 to Pyro5. With our usage of the RPC being limited to control functions, I would propose that we use varlink. RFC.

[fmoessbauer]

All these implementations are easy to use, but suffer from interface stability. How about switching to gRPC? This might be more effort, as we need to write the definitions for the interfaces, but at the same time it protects us from accidental interface changes.

[chombourger]

created a next branch to let us implement #524 until it is ready

[fmoessbauer]

We just stumbled upon this again in an mtda lab that uses Pyro5 from trixie. If we want to support larger deployments, we need a stable ABI between the client and the server. I'm further proposing to make the RPC interface explicit, so the mtda-cli package and the mtda package can be split (currently you need system python bindings just to run the client).

An alternative would be to just provide a REST interface (as we already have for the UI) and use that for the CLI as well. Technically I don't see a reason against this.

[bniedermayr]

An alternative would be to just provide a REST interface (as we already have for the UI) and use that for the CLI as well. Technically I don't see a reason against this.

I would vote for this.

Using REST would reduce the number of distinct ports to use. Especially interesting and sometimes crucial for setups behind a firewall (#562). IMHO the communication could then run over a single port where the desired functions (webUI, video stream, console etc.) could then be provided by different REST endpoints that might establish (if required) websockets between the client and server.