Commit pending state changes before updating client in testing pkg

[colin-axner]

Summary

The testing package has a NextBlock function which commits the current block and begins the next block. It should commit to the current working app hash. Currently it commits to the app hash which was set when the block had begun, causing any writes to the block to require 2 commits to be proved (one commit to clear the current block and a second to make the state changes provable)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[colin-axner]

see #3846 (comment)

[colin-axner]

We can likely take the app hash from FinalizeBlock in the eden upgrade, see here

I tried using the chain.App.LastCommitID().Hash after calling chain.App.Commit() in the existing code, but this breaks proof verification for some reason? Need to investigate some more, but I believe this might actually be expected behaviour. Since I believe cometbft commits to a header before executing state changes, so state changes are actually reflected in the next signed block header

[colin-axner]

This issue should produce two blocks before an update client (one to commit the currently proposed header and one to make available the pending state changes produced by tests), it might be possible to remove one commit if you can see if the working hash == latest commit hash (but this would be an optimization, maybe we could leave a descriptive comment to explain the behaviour)