Reduce masp events

[grarco]

Right now, if a transaction contains at least a valid masp transfer, we emit two attributes in the tx event:

1. masp_tx_block_index to point to the transaction in the block
2. masp_tx_batch_refs to point to the the section(s) containing the masp data

These two attributes always go together, they are either both present or non of them is. We should try to collapse them into a single attribute.

Also, we should try to see if it is possible to manage this attribute in a batch without the need for ExtendedTxResult.

[grarco]

After some attempts, I concluded that the last part of this issue cannot be achieved. We want to emit a single masp attribute per tx event (also because we don't have support to build dynamic attribute identifiers): so we cannot emit the event for every tx in a batch (using the ´event´ field of BatchedTxResult). At the same time, we don't have an already available support structure where to dump the masp data coming from every inner transaction: to create one would simply mean to circle back to something similar to the ExtendedTxResult type we wanted to remove.

[brentstone]

Thx, so what is the priority level of accomplishing the first part of this issue would you say?

[grarco]

Actually, I'm reopening this as it is possible to achieve the last part of this issue by emitting a separate MASP event instead of adding it as an attribute of the Tx event. We should leave the task of emitting the event up to the tx itself directly from wasm (we could probably remove the MaspAction we use to signal the data blob and use the event instead since we have to emit it anyway). Once we've done this we can remove the ExtendedTxResult type. The depending tools (such as the masp indexer) should be updated though

[grarco]

By emitting an event though we are subject to the limitation of batch events: if more than one masp tx is present in the batch (e.g. relaying of ibc messages), the clients (and indexers) will not necessarily see the events of the batch in the correct order: we should either address #3856 first or emit masp events containing also a counter so that clients can reconstruct the correct order of events.

[grarco]

See also namada-net/namada-indexer#267 (comment) for another small issue with these events being represented in a simple Vec: recovering the actual inner tx in the batch that generated the given masp event is a bit tricky since we don't have a direct mapping in the event itself, which slightly defies the purpose of emitting these events in the first place (which was to ease the task for indexers)