Feat: Genericise state access

[jmcph4]

Describe the feature you would like

We need much stronger separation of concerns between the logic side of the library (i.e., swap simulation, state synchronisation, etc.) and the glue side. In principle, it shouldn't really matter how we got the state (nor where we got it from) in order to compute the price of a swap in a given pool. Conceptually, there are three ways to retrieve state:

• Via any Ethereum node, via any of the three major transports
  • HTTP
  • Websockets
  • IPC (Unix domain sockets, etc.)
• Via Reth, programmatically (i.e., using Reth as an SDK)
• Via the Reth database directly (i.e., from the filesystem)

#239 touches on the latter two and the library already supports the first approach. Ideally, we would unify all three approaches whenever we write code that needs to perform checkpoint sync, price calculation, etc. There are a variety of approaches here:

1. A new trait of our definition
2. An enum that combines all of these
3. Wrap a Reth StateProviderFactory into an Alloy Provider using alloy-reth-provider

I understand that Option 3 is somewhat ugly in that we're potentially composing an Alloy provider into a Reth provider into another Alloy provider; however, I feel that this is the simplest approach for the library itself as it allows us to solely rely on an Alloy Provider as we do currently.

---

Edit: I think what we need is the following:

graph RL
    Reth --> Alloy["Alloy Provider"]
    Remote["Remote (via cakevm/alloy-reth-provider)"] --> Reth
    State["In-process Reth (via paradigmxyz/reth#13127)"] --> Reth
    Database["Direct-to-Database (via darkforestry/amms-rs#239 or cakevim/rethdb-dexsync)"] --> Reth
    Real["Real (i.e., a regular Alloy Provider)"] --> Alloy
    HTTPS --> Real
    Websockets --> Real
    IPC --> Real

Loading

Additional context

No response