explicitly propagate events from cached contexts to original context in delaymsg endblocker

[tqin7]

Context:
Couldn't find bank transfer events when a bridge is completed.
x/gov explicitly propagates events from cached contexts (see here)

Testing:
Ran localnet

1. Before this change, can't find the bank transfer events in end_block_events in /block_results response
2. After this change, can find the bridge bank transfer events in end_block_events in /block_results response
   example:

   {"type":"transfer","attributes":[{"key":"recipient","value":"dydx1zg69v7yszg69v7yszg69v7yszg69v7ysuz0wqr","index":true},{"key":"sender","value":"dydx1zlefkpe3g0vvm9a4h0jf9000lmqutlh9jwjnsv","index":true},{"key":"amount","value":"123dv4tnt","index":true}]}
   

[linear]

CORE-608 find emitted transfer events when bridging

[teddyding]

I had question about events being correctly emitted in this PR (cc @clemire ). It looks like the test we added here was not sufficient to catch this?

Can we add a test that correctly verifies events in delayed messages emitted? (we should verify it fails without the fix in this PR)

[teddyding]

We should wrap this event emitting logic in RunCached util, if possible. Does the axelar example util work?

[clemire]

Can you double-check that such a change doesn't cause events to be emitted twice? I think the writeCache method does emit events, so I'm wondering if the returned events for this transfer did not get added to the cachedCtx event manager, and that's why they were missing. In that case, handling this from RunCached may not be the solution.

[dalmirel]

There were a lot of issues due to sdk message handler creating new EventManager. The emitted events could be picked up from the result like in: cosmos/cosmos-sdk#13389
or just propagate events like axelar did and @teddyding is suggesting.I believe Axelar as well had issues with losing events with their initial RunCached implementation: axelarnetwork/axelar-core#1439.

[tqin7]

When I emit events in RunCached like axelar example, they don't show up any more. The reason is that message handlers create a new event manager and thus the events aren't present in ctx.EventManager() in this line (The cosmos issue that @dalmirel linked also mentioned the same issue)

I think for x/delaymsg's use case, we have to emit events that are part of handler response

[tqin7]

I had question about events being correctly emitted in this PR (cc @clemire ). It looks like the test we added here was not sufficient to catch this?

Can we add a test that correctly verifies events in delayed messages emitted? (we should verify it fails without the fix in this PR)

added a test case in second commit that fails without the fix!

[tqin7]

As a separate ticket, I think we should also add this line to our RunCached implementation