Implement retry/resume functionality for [create] & [setup] steps

[anuragchvn-blip]

PR Description for Issue #71 Implementation

Title: Implement retry/resume functionality for [[create]] & [[setup]] steps

Description:

This PR implements the retry and resume functionality for both [[create]] and [[setup]] steps as requested in issue #71.

Changes Made:

1. Create Steps Resume:

   • Added logic to check existing entries in the named_txs table before deploying contracts
   • Contracts that already exist in the database are skipped during subsequent runs
   • Proper counting mechanism to track multiple deployments with the same name

2. Setup Steps Resume:

   • Created setup_progress table with scenario_hash and last_step_index fields
   • Added get_setup_progress and update_setup_progress database methods
   • Implemented step indexing to track completed setup transactions
   • Resume execution from the last completed step

3. Database Schema:

   • Added setup_progress table: (scenario_hash TEXT PRIMARY KEY, last_step_index INTEGER NOT NULL)
   • ON CONFLICT handling for progress updates

4. Error Handling:

   • Proper failure handling that preserves progress when setup steps revert
   • Execution stops on failure while maintaining completed steps

Technical Details:

• Create steps use name-based lookup in named_txs to determine which deployments to skip
• Setup steps use scenario hash-based progress tracking with step indexing
• Both implementations handle the redeploy flag properly
• Progress is preserved in the database for resumable execution

Testing:

• Database-level tests validate the setup_progress functionality
• Integration tests verify the resume behavior works correctly
• Existing functionality remains unchanged

This resolves issue #71 by allowing users to resume failed scenario deployments without losing progress.

[zeroXbrock]

this is a great first pass, thank you @anuragchvn-blip!

Just a few notes:

DB_VERSION needs to be incremented -- when users update their contender client, their DB will still be on the old version. Updating this value makes sure that updated clients with the old DB schema know to update their DB.

The simulation stage improperly skips setup steps. I noticed that when I tried to simulate a failure (by shutting down my node during setup) and retried, the simulation stage skipped all the setup steps (presumably because we ran them before in anvil). We should still be able to skip steps in the sim (if we've finished that step onchain), because the sim chain is a fork of the target chain, but first we need to properly identify the target chain for resumption (next point).

I noticed that when I spun up a new chain and ran the same setup again, the setup steps were skipped. I attached some comments to the code that suggest a solution to fix this.

Looking forward to your next commits, super excited about this feature!

[zeroXbrock]

I think scenario_hash should be a FixedBytes<32>, then we can convert it to a string for the DB here -- this trait shouldn't have to worry about improper hashes being given as input.

[zeroXbrock]

scenario_hash should also be compounded with genesis_hash so we can identify the setup per-chain. Right now, setup steps are skipped for chains that have never setup the scenario.

My solution for this would be to add genesis_hash to the args (for get_setup_progress and update_setup_progress), then concat the hashes and re-hash to get the scenario_id we actually use as the DB index.
Something like this:

let scenario_id = keccak256([
    scenario_hash.as_slice(),
    genesis_hash.as_slice()
].concat());

also do this in update_setup_progress