Filter events before reply block

[ethanfrey]

Closes #587

• Add failing testcase showing messages make it into reply block
• Ensure reply doesn't get event(message)
• Ensure submessage event(message) doesn't make it out with no reply block
• Remove no-longer needed event(message) filtering in DefaultWasmVMContractResponseHandler.Handle
• Update other tests as needed

[ethanfrey]

Ready for review.

Added a few tests to assert the "message" events were not returned from DispatchSubmessages, nor ever returned to the Reply call.

Fixed/removed a few other tests that expected to find messages.

[codecov]

Codecov Report

Merging #589 (7fbf513) into master (7b2e84c) will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #589      +/-   ##
==========================================
+ Coverage   59.86%   59.92%   +0.06%     
==========================================
  Files          45       45              
  Lines        5197     5200       +3     
==========================================
+ Hits         3111     3116       +5     
+ Misses       1862     1861       -1     
+ Partials      224      223       -1     

Impacted Files	Coverage Δ
x/wasm/keeper/keeper.go	86.97% <100.00%> (+0.24%)	⬆️
x/wasm/keeper/msg_dispatcher.go	87.23% <100.00%> (+1.02%)	⬆️

[alpe]

👍 Looks good and works as expected 🌷

One note to reduce complexity in the filter

[alpe]

🤔 You can reduce complexity of this method a lot by just accepting []sdk.Event. On the caller side just do: filterEvents(append(em.Events(), events...)). I would not expect thousands of events that require some optimization.

[ethanfrey]

Okay, in Rust everytime you heap allocate to make vectors (slices), it is considered "expensive". I guess we do not micro-optimize so aggressively in Go.

I will simplify