feat(katana): experimental feeder gateway sync

[kariy]

This PR adds two pipeline stages for the initial full node sync implementation:

Stages

1. Blocks

• downloads bocks data, incl. state update and transactions
• from feeder gateway

2. Classes

• downloads class artifacts based on the state updates fetched in Blocks stage.
• from feeder gateway

---

To test out this feature, i've implemented a separate node type under katana_node::full module which is a lightweight copy of the primary Node struct but with sequencing features removed and runs the syncing pipeline.

dojo/crates/katana/node/src/full/mod.rs

Lines 39 to 44 in 9d2a169

	#[derive(Debug)]
	pub struct Node {
	pub db: DbEnv,
	pub pool: TxPool,
	pub config: Arc<Config>,
	pub task_manager: TaskManager,

This new node type doesn't have a rpc server for now because StarknetApi requires that the TransactionPool implementation is of the concrete type TxPool as it calls the TxPool::pool_nonce method in one of the rpc endpoint.

dojo/crates/katana/rpc/rpc/src/starknet/mod.rs

Lines 362 to 365 in 9d2a169

	let result = if let BlockIdOrTag::Tag(BlockTag::Pending) = block_id {
	this.inner.pool.validator().pool_nonce(contract_address)?
	} else {
	let state = this.state(&block_id)?;

Summary by CodeRabbit

Release Notes

• New Features

  • Introduced support for a new Deploy transaction type and legacy DeclareTx::V0.
  • Added methods to retrieve declared classes and deployed contracts from the blockchain provider.
  • Enhanced error handling in transaction processing and introduced new error types for stage-specific issues.

• Improvements

  • Improved transaction handling for various versions, including better fee and nonce management.
  • Enhanced modularity and clarity in the pipeline's block and class management.

• Bug Fixes

  • Fixed logic for handling transaction types to ensure consistent behavior across versions.

These updates enhance the overall functionality and user experience of the Katana system.