fix(fork-network): flush the first pass changes before starting the s…

…econd pass (near#12121)

There is a corner case where the last batch of changes is smaller than
the batch threshold and it may not get flushed before the seconds pass.
This will recreate the keys for the accounts that were deleted in the
uncommitted batch.

To test this, we created a network with a validator and an RPC
node.
Created an account (`A` with key `Ka`) by sending some `$N` to
it.
 Add another key to that account (`Kb`). Now `A` has `Ka` and `Kb`
as full access keys.

Delete `Ka`. Now `A` has just `Kb` as full access key.

On this state, we run `fork-network`.

In the first pass, we change account `A` to `rA` and delete `A`. 
Change key `Kb` to `rKb` and delete `Kb`.

Without this fix, the default batch size is too large to flush the
changes from the first pass of `prepare_shard_state`.

Moving to the second pass, the `A` implicit account is still in the flat
state and we will add a key to it.

If we flush before the second pass, account `A` will no longer be in the
flat state.

tools/fork-network/src/cli.rs

@@ -620,6 +620,25 @@ impl ForkNetworkCommand {
             }
         }
 
+        // Commit the remaining updates.
+        if storage_mutator.should_commit(1) {
+            tracing::info!(
+                ?shard_uid,
+                ref_keys_retrieved,
+                records_parsed,
+                updated = access_keys_updated
+                    + accounts_implicit_updated
+                    + contract_data_updated
+                    + contract_code_updated
+                    + postponed_receipts_updated
+                    + index_delayed_receipt
+                    + received_data_updated,
+            );
+            let state_root = storage_mutator.commit(&shard_uid, fake_block_height)?;
+            fake_block_height += 1;
+            storage_mutator = make_storage_mutator(state_root)?;
+        }
+
         tracing::info!(
             ?shard_uid,
             ref_keys_retrieved,