refactor: seperate protocol verification from RPC logic

[fnerdman]

I propose a refactoring of the Helios Light Client codebase to separate the protocol verification logic from its RPC dependencies. This focused refactoring aims to enhance modularity and flexibility by isolating protocol-related concerns.

Objective

The primary goal is to create a non-interactive verifier component, decoupled from RPC logic, specifically concentrating on protocol verification - allowing it to function as a standalone crate.

Benefits

Isolating the protocol verification logic in the Helios codebase enhances modularity, simplifying code structure. This improvement also enhances the extensibility of the codebase for future developments

Maintainer Input & Implementation Considerations

I'd like to request input from maintainers to gauge support for this specific refactoring. Also any hints on the best approach for separating protocol verification from RPC logic, or any concerns to this approach would be much appreciated.

Related Notes (see #252)

Consensus Checking without Async: Currently, using the consensus checking parts requires an async runtime. Discuss the possibility of allowing the consensus-critical part to function without an async runtime.

[ncitron]

Yeah I agree this is a good idea. I've been thinking about working on a no_std compatible feature which would basically be this as well.

I was thinking the interface could just have a function to sync, that takes in a bootstrap and a list of updates, and one more function that can apply a new update to the state.

This of course doesn't support automatically keeping up with the head state, as that would require RPC access as well as some async code to handle sleeping without blocking the thread.

Is similar to what you were thinking?

[fnerdman]

Yes, that aligns with the idea. A light client library with a very simple interface to be used for custom non RPC implementations would be very interesting.