feat(client): providers generic over oracles

[zobront]

Description

This PR includes a range of changes that will make it easier for our zkvm-client (and likely future integrating teams) to work with kona-client directly rather than forking and modifying it.

Changes:

• The CommsClient trait encompasses PreimageOracleClient + Clone + HintWriterClient. Therefore anything that implements this trait (which will be the Oracles) can both fetch and hint data.
• Update CachingOracle to include the hint writer, and therefore properly implement CommsClient.
• Providers perform all hinting and fetching via self.oracle (which implements CommsClient) and therefore never need to access the hint writer directly. This includes TrieDBHinter, which is now implemented on L2Provider rather than requiring the TrieDBHintWriter type.
• A zkVM io type is added that is unimplemented. This doesn't do anything because we don't use the io system at all in the zkVM, but is required for compilation.
• The PreimageKey type in the preimage crate now has an rkyv flag for serialization instead of serde. This is used for more efficient serialization that is better for us when passing data into the zkVM.

Tests

N/A

Additional context

N/A

Metadata

N/A

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.7%. Comparing base (a4ae5f5) to head (e44c42e).
Report is 19 commits behind head on main.

Additional details and impacted files

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zobront]

@clabby I understand the logic for keeping a separate Fetcher and Hinter in the library crates, as we want to keep flexibility for future users to implement these separately.

But if we are going to have the L2 Provider fulfill both of these roles in kona-client, do you think it makes sense to refactor FPVMPrecompileOverride to just be generic over a single type that implements both traits?

[refcell]

Since this simplifies the ux and isn't clear who will need the split logic, I support doing this refactor in a follow-on pr. The FPVM Precompile Override can always be made even more abstract by encapsulating it's internal logic in a trait, so not too worried about increasing the abstractions here.

[refcell]

Generally looks good - just have a preference to keep serde as a feature flag with mutual exclusion.