Async Ack

[chipshort]

also fixes #1891

I had to do changes in quite a few places

[srdtrk]

Lgtm. Added some comments :)

[chipshort]

I moved this call into the keeper now (was in IBCHandler before). That makes the whole thing a little easier to understand, but now we have to convert the packet back into a channeltypes.Packet

[codecov]

Codecov Report

Attention: Patch coverage is 38.31776% with 66 lines in your changes missing coverage. Please review.

Project coverage is 54.68%. Comparing base (5ae2f4a) to head (eeb3cd4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1876      +/-   ##
==========================================
- Coverage   54.87%   54.68%   -0.20%     
==========================================
  Files          65       65              
  Lines        9775     9857      +82     
==========================================
+ Hits         5364     5390      +26     
- Misses       3866     3919      +53     
- Partials      545      548       +3     

Files	Coverage Δ
x/wasm/client/cli/tx.go	15.18% <ø> (ø)
x/wasm/keeper/keeper_cgo.go	94.11% <100.00%> (ø)
x/wasm/keeper/relay.go	79.38% <68.42%> (-1.87%)	⬇️
x/wasm/types/keys.go	52.30% <0.00%> (-8.41%)	⬇️
x/wasm/keeper/keeper.go	76.82% <41.66%> (-1.14%)	⬇️
x/wasm/keeper/handler_plugin.go	64.70% <31.48%> (-15.49%)	⬇️

[webmaster128]

Great stuff.

I am just wondering about one thing: how to cleanup this temporary packet store at some point for the packets that get never acknowledged. Would be great to have some sort of configurable lifetime.

[webmaster128]

We should have a go mod tidy check in wasmd (just like wasmvm)

[chipshort]

how to cleanup this temporary packet store at some point for the packets that get never acknowledged. Would be great to have some sort of configurable lifetime.

That's a general problem with async acks, even on the ibc-go layer. If there is no ack, the packet commitment is not deleted there either.
Adding a lifetime opens a whole different can of worms. When would we clean it up?
Also, I'm not sure how a valid contract should handle that case. After deleting the stored packet, there is no way to ack the packet anymore, so that can in theory cause a packet that would otherwise have been acknowledged to get stuck.

I'm not convinced there's a good solution for this, so my take is to just live with the fact that incorrect contracts will write packets that are never cleaned up (just like they can write stuff into their own state that never gets cleaned up).

[webmaster128]

my take is to just live with the fact that incorrect contracts will write packets that are never cleaned up

Right, sounds good. In that case should we add a storage write fee to StoreAsyncAckPacket? Or does prefixStore.Set(key, packetBz) charge gas automatically?

[chipshort]

Yes prefixStore.Set(key, packetBz) will charge that. You can see an example in the test in relay_test.go.

[webmaster128]

Beautiful