Draft: Differentiate rpc_server and restrict sequencer

What

This Merge Request enhances the differentiation of RPC services across node types:

• Sequencer Node: Provides RPC services relevant to both multi-chain and single-chain contexts, restricting available methods to those necessary for sequencers.
• Non-Sequencer Node: Supports RPC services exclusively within single-chain contexts, further specialized by chain family. This category includes:
  • Observer Nodes
  • Proxy Nodes

Additionally, it limits the sequencer RPCs to the following:

Rollup RPCs:

• eth_blockNumber: Now computed independently of a specific chain, using the predecessor of the next blueprint number.
• /evm/smart_rollup_address
• /evm/time_between_blocks

Blueprint RPCs:

• /evm/blueprint/<n>: Query parameter extended with an optional chain_id field.
• /evm/blueprints: Same update as above.
• /evm/messages: Same update as above.

L2 Chain RPCs:

• eth_sendRawTransaction: The transaction parameter already includes a chain_id, allowing correct routing to the appropriate tx-pool.

How

This MR updates all node main functions to read the chain_family value provided by the kernel and pass it as a parameter to the rpc_server.

The chain_family is then propagated through the execution stack until method resolution occurs, where supported and unsupported methods are filtered based on rpc_server_family. This approach ensures that:

• Sequencer methods are properly restricted.
• The method lists for evm and michelson nodes remain intact.

Other MRs

This will break many tests that query the sequencer to RPCs that it does not supported anymore. Another MR is being done to keep these tests working.