Make rollback command usable to fix missed hard upgrades

[tsutsu]

Fixes #9174.

This PR addresses this edge case, by making the tendermint rollback command also remove the blockstore data for the block from which the invalid app-state was derived. This fixes cases where it's not the application's execution of the block that's incorrect, but the block itself that's invalid. (Presumably this condition only ever pertains in a hard-fork scenario — i.e. when a block that would be valid under node-software version N, becomes invalid under node-software version N+1; and such a block is produced by a validator who hasn't upgraded to version N+1.)

This code has been smoke-tested in a real-world use-case: I wrote this code "in anger", as a hotpatch to fix an evmos node that was experiencing exactly the problem described in #9174, so that the node could resume sync rather than needing to re-start sync from genesis. It worked!

Coincidentally, adding this logic also enables tendermint rollback to be used repeatedly, to walk the state back by more than one block. Previously, once tendermint rollback had been used once, the "state height + 1 == blockstore height" branch of state.Rollback would always be followed, early-returning success without doing anything. This code-path now just removes the blockstore data for the "pending" block before proceeding to purge the state + blockstore of the "latest" block.

PR checklist

• Tests written/updated, or no tests needed
• CHANGELOG_PENDING.md updated, or no changelog entry needed
• Updated relevant documentation (docs/) and code comments, or no
  documentation updates needed

[cmwaters]

Thanks for opening this PR. I think the hard-fork scenario is a valid case. I will try to review this once I get a few free cycles.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thanethomson]

@cmwaters did #9261 supersede this PR?

[cmwaters]

Yeah. I'm going to close this PR in favour of #9261.