sozo: remove the need of world_block

[glihm]

Currently, sozo needs to fetch data from the world to have compare it to the local representation of it.

However, on public networks, when too much blocks are in the network, the nodes are refusing returning data if the block range used to get events is too big.

As a temporary fix, sozo is relying on a world_block parameter:

dojo/crates/dojo/world/src/config/environment.rs

Line 13 in a2f00ed

pub world_block: Option<u64>,

And this is used in sozo here:

dojo/bin/sozo/src/commands/events.rs

Lines 65 to 71 in a2f00ed

	let from_block = if let Some(world_block) =
	profile_config.env.as_ref().and_then(|e| e.world_block)
	{
	Some(BlockId::Number(world_block))
	} else {
	self.from_block.map(BlockId::Number)
	};

The idea of this issue, is to remove this world_block, and instead making smaller block ranges if sozo detects the block range is too wide.
The exact limit of blocks is not benched yet, but 50k blocks could be a good start.

*** EDIT ***

The most important part to update with this PR is actually where we are rebuilding the remote world. Currently this is a big issue since the world is not rebuilt correctly which impacts almost all the commands. sozo event is the only command doing the raw logic since we need raw events access.

dojo/crates/dojo/world/src/remote/events_to_remote.rs

Line 26 in c989595

pub async fn from_events<P: Provider>(

[pheobeayo]

Can I handle this task?

[glihm]

Can I handle this task?

Yep, feel free to ask on the dojo discord or here if you have any question!

[glihm]

@pheobeayo how are you going on this? Any update?

[pheobeayo]

@glihm I will be making a PR soon

[okhaimie-dev]

@glihm can you reassign this issue to me?

[glihm]

@pheobeayo is also interested to learn, don't hesitate to catch up with @okhaimie-dev to collaborate on that if you're willing to.

@okhaimie-dev I've also updated the issue, with what needs to be adjusted.
Thanks for your contribution guys.