Add "Sent" event when a message is sent via execute

[franciscoaguirre]

With the extrinsics in pallet-xcm, we always emit the Sent event when a message is sent as a result of our actions:

polkadot-sdk/polkadot/xcm/pallet-xcm/src/lib.rs

Line 1825 in 48c6574

let e = Event::Sent { origin, destination: dest, message: remote_xcm, message_id };

We're moving towards a future where we encourage the usage of pallet-xcm.execute() over highly specialized extrinsics. One missing piece for this is that when calling execute, no event is emitted when a message is sent.
We should emit the Sent event everytime execution results in sending a message:

polkadot-sdk/polkadot/xcm/xcm-executor/src/lib.rs

Line 417 in 48c6574

fn send(

The problem with this is that emitting events is something pallets do, not the executor, so we don't have access to it. We have access to the XcmRouter which delivers the message.
We have to give the executor access to the pallet in some way.

Two ways that I see of doing this:

1. Adding a new configuration item, something like EventEmitter, which we can plug in and use to emit the event we want. Downside of this is it's a breaking change since we add a new associated type to the config.
2. We provide the pallet as another generic of a particular XcmRouter, for example ParentAsUmp and then use that to emit events. With this we don't introduce a breaking change but still manage to emit events as long as our routers have this logic.

[acatangiu]

Can we make the executor emit events? I believe there are multiple places in the executor where we should emit events for visibility and traceability - ideally executor would emit these directly.

Otherwise, we can go with your first suggestion and add config EventEmitter and have pallet_xcm implement and emit all types of relevant events.

[franciscoaguirre]

Events are a FRAME concept. The executor uses the config for accessing these functionalities so I think we should use that mechanism for events.

A single config for emitting all events might be a good compromise. However, this would be a breaking change. We could do that for stable2503 so we pile all events we want there but we can backport option 2.

[acatangiu]

I would go with the proper change even if it is braking and thus cannot be backported. I would prefer to avoid technical debt where we can, and this issue doesn't look urgent enough to warrant taking on temporary workarounds.

So, I ultimately support your option 1: add config EventEmitter and have pallet_xcm implement and emit all types of relevant events.