feat(sdk): add types and use builder pattern

[mattstam]

This PR updates the network-v2 SDK with:

• Add types for request_id, vk_hash, and tx_hash instead of just bytes
• Builder pattern to configure everything
• Custom error types using thiserror (e.g. to implement different logic for unexecutable vs unfulfillable)
• Removal all unwrap / expect statements and bubble up all errors correcty
• Example of using NetworkProver

New options for using ProverClient to request proofs:

    let client = ProverClient::new();

    // Generate the proving key and verifying key for the given program.
    let (pk, vk) = client.setup(ELF);

    // Generate the proof, using the specified network configuration.
    let proof_result = client
        .prove(&pk, stdin)
        .strategy(FulfillmentStrategy::Hosted)
        .cycle_limit(20_000)
        .timeout(Duration::from_secs(3600))
        .skip_simulation()
        .run();

note, because we are using ProverClient, we need to downcast the error:

    // Handle errors from proof generation.
    let mut proof = match proof_result {
        Ok(proof) => proof,
        Err(e) => {
            if let Some(network_error) = e.downcast_ref::<Error>() {
                match network_error {
                    Error::RequestUnexecutable => {
                        eprintln!("Program is unexecutable: {}", e);
                        std::process::exit(1);
                    }
                    Error::RequestUnfulfillable => {
                        eprintln!("Proof request cannot be fulfilled: {}", e);
                        std::process::exit(1);
                    }
                    _ => {
                        eprintln!("Unexpected error: {}", e);
                        std::process::exit(1);
                    }
                }
            } else {
                eprintln!("Unexpected error: {}", e);
                std::process::exit(1);
            }
        }
    };

Example of error bubbling up and handling it in network.rs:

2024-12-07T03:11:11.555279Z  INFO Client circuit version: v3.0.0    
2024-12-07T03:11:13.476067Z  INFO Registering program with verifying key hash    
2024-12-07T03:11:13.777060Z  INFO Created request 0xf54964f7b707e1a0d40c578965106a794a8769e302e9e10c509bfa8a1924037c in transaction 0x76d8c2d2cc9d5847657966d83f331fdaee8bf1e296a24177c664746e96b639ec    
2024-12-07T03:11:13.783206Z  INFO Proof request assigned, proving...    
Proof request cannot be fulfilled: Proof request 0xf54964f7b707e1a0d40c578965106a794a8769e302e9e10c509bfa8a1924037c is unfulfillable

In a real situation, you may want to retry if it's unfulfillable or implement custom logic.

[github-actions]

SP1 Performance Test Results

Branch: mattstam/sdk-network-polish
Commit: 2cc6223
Author: mattstam

program	cycles	execute (mHz)	core (kHZ)	compress (KHz)	time	success
fibonacci	11291	0.18	2.81	0.46	24s	✅
ssz-withdrawals	2757356	17.73	127.96	35.22	1m18s	✅
tendermint	12593597	6.64	268.25	100.41	2m7s	✅

[mattstam]

flattening this to make the API clean e.g. use sp1_sdk::network_v2::{Error, FulfillmentStrategy}

[jtguibas]

RequestHash, to be consistent?

[mattstam]

It's request_id everywhere in the proto, on the RPC, and on the frontend - to avoid a massive refactor I feel like leaving at RequestId is fine

[ratankaliani]

nit: Should we really use a string here? Seems like B256 may be a better choice.

Alternatively, Alloy has the same problem and has a reasonable type that they expose for this: https://github.com/alloy-rs/alloy/blob/main/crates/signer-local/src/lib.rs

[mattstam]

I'm open to it, although String seems the most versatile, as otherwise the client needs to import Alloy / whatever type we enforce.

[mattstam]

note: the actions prove struct, context builder, and proof opts seem kinda clunky to me (at least for using things on the network) - for example, it's not clear why max_cycles is not simply a field

but refactoring all this is out of scope of this PR, no users really see this anyway