Description
Currently katana only provides forked data for state-related info (eg storage, nonce, class hash) thru the SharedStateProvider. We should extend the forking functionality to also allow fetching non-state data as well (eg block, events, tx) from the forked network.
We can extend the Backend to handle more request types.
Proposed solution
We can mimic ForkedStateDb where it uses SharedStateProvider as the underlying db for CacheStateDb by creating similar forked provider type specifically for the CacheDb instead, that handles non-state data (ie block, tx). Unlike SharedStateProvider, we don't have to implement the provider traits as most of the traits are mainly for abstracting over the db layout. We only need to fetch data that can only be fetched from the RPC. So, that means we only need to implement fork handlers for data that can only be obtain from the Katana RPC.
Regarding caching (ie storing the fetch forked data into local storage), ideally we can store the fetched data directly into the main storage, but how the storage is laid out at the moment isn't very friendly to unordered insertion like this case. Maybe we can have the forked provider type to include a storage to store the data fetched from the forked RPC.