Create AGL webapp API for wrapping dbus launcher API

Close for MM 13.0.0

Marking as implemented: https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-demo/+/27237

Further plans for gRPC should be planned in the future, once we start migrating to a possible future IPC.

I will attend next week call. gRPC definitely could work as system IPC, the same as using web sockets. Main problem is the need to add an authentication or filtering mechanism so each application can safely only access the services it is allowed to. Also, gRPC is not supported in web platform, and we will need a proxy service (like Envoy) if we want to access those services directly from web code.

On the other hand, the approach I am taking for web services, using injections and web existing APIs, has some advantages:

• It is independent from the system IPC mechanism. So now I can use dbus, but if we move to use gRPC or web sockets, then the abstraction implementation will move to use it while keeping the same API for web applications.

• It is quite secure: permissions are given enabling the extensions only for certain applications, following the application manifest. So no authentication needed here.

• We prefer to use existing API in web platform if possible to avoid applications to require much AGL specific code if possible.

• It works for local applications without requiring a local HTTP server.

For the record, many of this considerations are known also in webOS side, where they dropped D-Bus because of performance at that time (I don't think that's a problem anymore), but also because of poor web adaptation. Their replacement, luna-service2, the webOS system IPC, has an API that is easy to embed in web, and has a security model that allows services to provide only certain IPC calls to certain applications. The IPC API is also bridged in NodeJS and WAM, and has implementations available in C/C++. If we want to have a non-D-Bus system IPC, it is interesting to understand the requirements and specifications of luna-service2 to write our one replacement, or to add a security model around gRPC or web sockets.

I think also this should be first discussed in the appfw call.

I think whether we stick with using D-Bus for much of anything at all in Needlefish and beyond is on the table.  I personally don't intend to write any new services that use it unless there is a hard directive to do so.  And given some of the pain I see with using glib D-Bus stuff, I'm highly inclined at this point to switch to just once again wrap BlueZ and ConnMan access in something else (e.g. grpc) that would avoid that and also end up with better support for sandboxing.  As to whether we stick with ConnMan as the network manager, nothing concrete has been discussed, but there are telematics and probably container usecases where I personally think Network Manager is likely more workable for anyone building an actual product (and I've been told about products that do use it), so I consider it a possibility that we switch at some point.  I would highly recommend that someone from Igalia attend the app framework EG calls going forward to discuss these topics.