[Feature]: (x/group) - add event for when a proposal vote is finalized

[clevinson]

Summary

Querying for proposal status (ACCEPTED, REJECTED, ABORTED, etc.) after a proposal has been pruned from state requires building external event indexers of votes and decision policies in order to recreate the final tally result. In development of the Groups UI MVP being worked on by Regen Network, we are wanting to include a view that shows the status of historical proposals, to act as a public record of actions and decisions voted on by the group. Adding an event when a proposal gets pruned, executed, or closes its voting period with the final tally result would make building UIs for groups significantly easier.

Problem Definition

In the current group module implementation, all proposals get pruned from state (either upon msg execution, or after a fixed duration after voting period ends). Currently querying the final tally and proposal status of a pruned proposal would require indexing both EventVote events, and requires querying historical state of an archive node to see the DecisionPolicy and member count of a group policy at the time of proposal creation.

This indexing process needs to duplicate any logic of the DecisionPoilcy, and also has the maintenance burden of needing to be kept up to date to support caluctaing vote results based on new decision policies that will be supported in the future.

Proposal

Emit a new event when a proposal's vote is finalized. There are a few ways that this could be constructed (after researching a bit how the group module deals with vote tallying):

1. Emit a EventProposalPruned whenever a proposal get's pruned from state, containing final tally information. This insures that all historical proposals' final tallies can either be queried directly from state (before it gets pruned) OR by querying EventProposalPruned events.
2. Emit a EventProposalVotePeriodEnded at the conclusion of a voting period. It's unlcear whether or not it would be approriate to emit this event in the case where an accepted proposal is executed before the VP ends.
3. Emit a EventProposalTallyFinalized whenever a tally is finalized. This would happen at conclusion of a voting period or upon msg execution (if executed prior to voting period ending). Querying this event could be always used as the way to get any finalized result.

In cases (1) and (3), it's worth noting that sometimes these events would be triggered from within the group msg server, but sometimes they would be triggered within EndBlocker, as that is when proposals often actually get finalized / pruned.

I believe (2) would only ever be emitted in EndBlocker, but there are some complications around (2) in that the current implementation of VP ending does actually know whether a given proposal has already passed its voting period at a previous block height. It only knows that at the current height the VP for a given proposal is over.

Preferred Approach

My preferred approach as (3), as it seems to provided the best Dev UX from the querying side, and is a semantically relevant action to tie an event to IMO.

Looking forward to hearing others thoughts on this. I'm happy to have us pick this up and start on a PR if there's alignment on the approach we should take.

[robert-zaremba]

It's indeed a limitation if you are using event based indexer. But the indexer framework can also deal with end-blocker.

[robert-zaremba]

Since events are not part of the block hash, this can be done and backported to 0.46 and 0.47

[aaronc]

This makes sense. Happy to support with a review. @tac0turtle any objections? Let's use a more succinct name than EventProposalTallyFinalized

[tac0turtle]

sounds good to me, lets see if someone can pick it up this week. Which version of the sdk are you on @clevinson

[clevinson]

Regen is on a fork off of v0.46.11. Would be great if this can be backported. But also, since we are already on a fork we can always cherry-pick this PR directly into our pre-existing fork if y'all don't want to go through a backport/release process.