Optimization of the op-env RPC interface

[lurenpluto]

During the optimization process of the A link, it was discovered that many current uses of global-state and object-map involve a large number of single operations, and there is room for optimization.

Since global-state and object-map must be processed through the op-env proxy, a typical read operation is as follows (taking the service manager's related code in the A link as an example):

CYFS/src/component/cyfs-stack/src/app/service.rs

Lines 142 to 146 in c1d9f9f

	let op_env = self.root_state_stub.create_path_op_env().await?;
	let path = format!("/app/{}/versions/{}", dec_id, ver_seg);
	let ret = op_env.get_by_path(&path).await?;
	let _ = op_env.abort().await;

CYFS/src/component/cyfs-stack/src/app/service.rs

Lines 95 to 99 in c1d9f9f

	let op_env = self.root_state_stub.create_path_op_env().await?;
	let path = format!("/app/{}/local_status", dec_id.to_string());
	let ret = op_env.get_by_path(&path).await?;
	let _ = op_env.abort().await;

The above is a typical example code, reading the value under the path from the root-state. It's a typical single read operation, but in reality, it initiates three RPC calls:

1. create_path_op_env

First, create the corresponding operation proxy.

2. get_by_path

The actual read operation.

3. abort

Cancel the use of op_env (for read operations, if this step is omitted, the target end will use the GC mechanism to recycle this op-env, which may slightly impact performance).

So a single read operation requires three RPC calls. If it spans across cyfs-stack and device, it can impact performance and there is room for optimization.

We can consider merging these three operations and providing single-RPC interfaces and protocols for individual read/write operations maybe.