feat: use tentacle spawn feature

[driftluo]

Currently, fiber does not rely on ServiceHandle's aggregation functionality, and forcibly aggregating it is not cost-effective. Using the Spawn feature might be better. The dependent init behavior has been changed to a once-in-a-time behavior, and the initialization time has been delayed from network startup to the first connection establishment.

[Copilot]

Pull request overview

Switches Fiber/Gossip protocols to Tentacle’s ProtocolSpawn model so per-session protocol handling is spawned on demand, delaying initialization until the first connection and avoiding ServiceHandle aggregation.

Changes:

• Replaced ServiceProtocol callbacks with ProtocolSpawn implementations that read from SubstreamReadPart.
• Introduced SharedControl (Arc) to share ServiceAsyncControl across clones and initialize once.
• Enabled Tentacle’s unstable feature to access the spawn API.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 4 comments.

File	Description
crates/fiber-lib/src/fiber/network.rs	Migrates Fiber protocol handling to ProtocolSpawn and reads messages from SubstreamReadPart.
crates/fiber-lib/src/fiber/gossip.rs	Migrates Gossip protocol handling to ProtocolSpawn, delays control initialization via SharedControl, and adds unit tests for SharedControl.
crates/fiber-lib/Cargo.toml	Enables Tentacle unstable feature required for spawn-based APIs.

[Copilot]

control is now set in ProtocolSpawn::spawn, which (per PR description) can be delayed until the first connection. Any actor code path that calls get_control() before the first spawn (e.g., interval ticks started in pre_start) will panic. Consider changing get_control() to return Option<&ServiceAsyncControl> (or Result) and make tick handlers/no-connection code paths no-op until control is available (or start the intervals only after control is set).

[Copilot]

SharedControl::set failures are silently ignored. If spawn is invoked more than once (multiple sessions, reconnects, or service restarts), this can hide unexpected state (e.g., control not matching assumptions). At minimum, handle the Err(value) case explicitly (log at warn!/debug!, or assert it’s expected) so operational issues aren’t silently swallowed.

Suggested change

	let _ = self.control.set(control.clone());
	match self.control.set(control.clone()) {
	Ok(()) => {}
	Err(_) => {
	debug!(
	"GossipProtocolHandle::spawn called with control already initialized; \
	ignoring new ServiceAsyncControl for session [{}], address: [{}], type: [{:?}]",
	context.id, context.address, context.ty
	);
	}
	}

[driftluo]

This is a pointless change. The protocol is set every time it's opened, but only the first time is successful; subsequent attempts result in errors. This can be ignored.

[Copilot]

With control initialization moved from init() to spawn(), interval-driven behavior can now run before ServiceAsyncControl is available. Add a unit/integration test covering the “no connections yet” case (e.g., actor starts, ticks fire, and it does not panic / does not attempt network control usage until control is set).

[Copilot]

Enabling Tentacle’s unstable feature can introduce semver-unstable APIs into downstream builds. If only a small part of the crate needs it, consider guarding spawn-based behavior behind a crate feature (or at least documenting in code/comments why unstable is required and what compatibility expectations are).

[jjyr]

Some crates in Cargo.lock are downgraded without reason, please keep them unchanged or upgraded.

 "socket2 0.6.2",
 "socket2 0.5.10",

[driftluo]

Some crates in Cargo.lock are downgraded without reason, please keep them unchanged or upgraded.

 "socket2 0.6.2",
 "socket2 0.5.10",

This should be a downgrade by cargo itself; the hyper-util dependency is written very strangely: socket2 = { version = ">=0.5.9, <0.7", optional = true, features = ["all"] }

A forced upgrade to socket2 restored the functionality.