[system] Introduce an Actor framework

[jolestar]

Rooch will have multiple components that need to communicate and call each other.

At this point, a framework for asynchronous communication calls is needed to simplify the development of component services. The Actor model is very suitable for this purpose.

However, there are currently no very usable actor frameworks in Rust, and there may be several options:

1. I use Actix to encapsulate an actor service framework at starcoin, which is used in the production environment. Still, it is not fully async mode and can be complicated when used with async. service-registry
2. @LemonHX has developed a new async actor framework (xtor)[https://github.com/starcoinorg/xtor] at starcoin, but it has not yet been officially used.
3. Encapsulate a simple framework based on Tokio, Async rust, and channel.

[lshoo]

There are many actor framework in Rust：	name	github repo	github stars	cluster support	version (latest update)
Actix	Actix	7.8k	--	v0.13.0 (2022-05-23)
ractor	Ractor	800+	yes	v0.7.5(2023-03-24)
Coerce-rs	Coerce-rs	480+	yes	v0.8.5 (2023-02-08)
Riker	Riker	900+	--	v0.4.2 (2020-11-30)
Bastion	Bastion	2.6k	yes	v0.4.5 (2022-01-08)

[lshoo]

I will focus on comparing the three latest updated frameworks:

1. Actix,
2. ractor
3. Coere-rs

[lshoo]

These two days, I briefly compared several Actor framework, the conclusion is that Coerce-rs is best, ractor is second, and Actix is third. Coerce-rs has a local actor, remote actor, actor custer, actor persistence, telemetry, etc., it's the most completion in the three candidate actor framework. Ractor has local actor, remote actor, and actor cluster features. Actix has local actor and remote actor features, but remote actor is not updated anymore For our project, remote actor, actor-custer, actor persistence are required features to build high available system, so Coerce-rs is used to build MoveOS service and Rooch network.

[jolestar]

We do not need too many features like remote actor, actor custer, actor persistence. We can choose a simple solution and make the system run first.

[lshoo]

ok， the local actors are fimilar.

[jolestar]

60

[ariesdevil]

We do not need too many features like remote actor, actor custer, actor persistence. We can choose a simple solution and make the system run first.↳

This is the right design, simple is better. I think it is important to note that all asynchronous tasks are constrained to use this actor framework, not a mix of non-actor and actor approach.