Introduce actor-based thin-edge components

[didier-wenzek]

Proposed changes

First step toward thin-edge Rust extensions

Types of changes

This PR provides:

• A new crate, tedge_actors, that defines how to implement, compose and test thin-edge applications using independent computing units that cooperate through messages over in-memory channels.
• A set of generic actors to support MQTT, HTTP, unix signals, inotify events, timers.
• A set of Cumulocity actors to handle configuration and log management.
• An executable that combines the features of the c8y-configuration-plugin and c8y-log-plugin, using the new actor design but with no external changes.

This PR has no impacts on the current thin-edge. The plan is to evolve concurrently the new and former design, porting the features progressively.

Paste Link to the issue

• POC to evaluate the proposals for a new core design around plugins and actors
• Gather requirements for thin-edge rust components

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[didier-wenzek]

Still to be done:

• Finalize the runtime.
• Derive the implementation of the message boxes that are simple records of message boxes.
• Fix fan_in_message_type! to accept arbitrary type expressions.
• Derive the implementation of a handle (as C8YHttpProxy) from a list of (request, response) type pairs?
• Consider to remove the ActorBuilder trait.
• Find a way to avoid a call to runtime.spawn(actor) for each and every actor.
• Can we have the message box owned by the actor instead of passing it as an argument to the run method?
• Move the code to extract the body of an http response, from c8y_configuration_poc to tedge_http_ext.
• Read C8YHttpConfig from tedge config.
• Move file_system_ext under crates/extensions
• Move c8y_http_proxy under crates/extensions
• Move config_manager under crates/extensions/c8y_config_manager
• Move log_manager under crates/extensions/c8y_log_manager

[didier-wenzek]

Any idea to improve this name?

• MessageBoxSocket, since this a way to plug a peer actor mailbox to this message box?
• ClientConnector, matching the name ServiceConnector, to stress this is to connect a client to a service?
• ClientSocket ?

[albinsuresh]

This trait would need more documentation to better convey its purpose as it's not that straight-forward even after looking at the concrete implementations.

[didier-wenzek]

Agree, the documentation must crucially be improved. => I will do that.

[didier-wenzek]

We will rename this trait as ActorPlug.

[didier-wenzek]

We are still looking for a better name.

• ServiceConsumer or ServiceClient or ServiceUser might be good candidates as this trait defines the requirements of an actor for some service provided by another actor.
• An alternative is also to deprecate this trait and use a combination of MessageSource + MessageSink .

This will be addressed as a follow-up task.

[albinsuresh]

A few general suggestions:

1. It might be better if the existing tedge_actor APIs could be split into two: The core APIs which just contains the core concepts like Actor, MessageBox etc and and ext set which contains all the utility stuff like Service, SimpleMessgeBox, KeyedSender etc. This will make the API exploration lighter even for an outsider as otherwise he'll be a bit overwhelmed with so many abstraction, where not all are required to write simple actors.
2. Error handling needs to be re-looked as many APIs expect ChannelErrors in the return type but a conversion of an actor specific error type to ChannelError is not straightforward. An anyhow::Error like approach would be easier for developers, which probably can be provided by just having a ChannelError enum variant that transparently wraps anyhow::Error

[albinsuresh]

This trait would need more documentation to better convey its purpose as it's not that straight-forward even after looking at the concrete implementations.

[albinsuresh]

This feature could be used to avoid this example code duplication. I wish it was a bit more mature to allow scraping smaller blocks of code from the source file as well.

[didier-wenzek]

Thanks for the link. However, I'm not fully convinced, the author having no way to tell which example to include in the doc and where (beyond that the documented function is used in these examples).

[albinsuresh]

Suggested change

	/// Create a message box pair (mostly for testing purpose)
	/// Create a message box with a `DualChannel` connected to it that can be used to send/receive messages to/from the message box (mostly for testing purpose).

My opinion: For some reason I find a "message box-channel" duo easier to convey than a message box duo, where one is connected to another. Especially because of the inverted Input/Output types in the generic signature of SimpleMessageBox<Output, Input>. I understand why it is like that, but I find a DualChannel<Input, Output> far more natural. But, this is just a personal opinion.

[didier-wenzek]

What do you have in mind with by a DualChannel<Input, Output> struct?

I understand that you want to grasp the concept of bi-directional channel; but, I don't see how you plan to use such a single struct while two independent actors that require a mutable access to it. A DualChannel must be a pair. Furthermore, one must be able to use specific message box types for each side: the types expected by the actors under test.

About the inverted input/output, note this is why I sometimes use request/response in such a context, along specific types as RequestResponseHandler that abstract this issue.

Compare:

type DualChannel<Input, Output> = (
      SimpleMessageBox<Output,Input>,
      ServiceMessageBox<Input,Output>
)

with

type ClientServiceChannel<Request, Response> = (
       RequestResponseHandler<Request, Response>,
       ServiceMessageBox<Request, Response>
)

In the former case, the input of one end is the output of the other and vise-versa. This is misleading. While in the later case the meanings of request and response is clear despite the RequesResponseHandler sends requests and receives responses.

[didier-wenzek]

Is this comment still relevant?