Ensure saved offchain solution matches creation snapshop

[kianenigma]

Related to paritytech/substrate#8641 and paritytech/substrate#8290.

We will support offchain worker resubmission soon. The problem is that the solution is created once and then sent blindly again. This can lead to bad solutions because the snapshot might have changed due to a revert.

Initially, we thought we can use fork-aware offchain storage, but that is not implemented.

Alternatively, in paritytech/substrate#8290 we fall back to just calling feasibility_check one last time before resubmission of cached solution to makes sure it is not faffy.

This is rather suboptimal. A nicer approach is to have a hash of the snapshot saved somewhere alongside the cached solution, so we can check it against the hash that is stored onchain.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[kianenigma]

Quite important. The OCW miners could repeatedly come to an wrong solution because of this.

[kianenigma]

This will actually not solve anything for the unsigned phase, because as long as you are in the same thread, you will surely read the same hash since you are in the same OCW thread.

note that if there is a long enough signed phase, this is not a big deal for the unsigned phase.

note that a good easy solution to all of this is to put a gap between snapshot and any submission.

lastly, we should have a safeguard in place, to make sure if for any reason OCW submission of any validator fails, then they do not retry in the same session.

[kianenigma]

This is still a nice addition, but very low quality, as doing a feasibility check before submitting offchain is not a big deal.

[kianenigma]

I checked this again. Indeed, we need to remember that within an OCW thread, the snapshot hash will always match, because even if we progress 10 blocks, the thread is blind to the progress. But:

1. When we go over the pool, in vlaidate_transaction, we could utilize this.
2. When we resubmit cached offchain solutions, we could utilize this.

This is a good, medium difficulty, low priority task. @Ank4n @gpestana either of you can pick it up as a side task.

[Ank4n]

I would like to attempt this and potentially pair with @gpestana if you are up for it?