Add account related txs and events

[Andrew7234]

I compiled+tested this prior to rebasing onto the openapi generated type changes. It will need to be rebased again once the codegen follow-up changes are merged.

It might be useful to go commit by commit, but only for the first 4 commits.

Open questions:

• The openapi spec calls consensus events ConsensusEvents but consensus transactions Transaction, which seems inconsistent. I'm in favor of renaming to Events, but we could also rename Transaction->ConsensusTransaction
• Since we support filtering events by type, we need to have some mapping of all the valid event types. This used to be adjacent to the Event type the api types, but now that event types are autogenerated the mapping is separate from the ground truth. This could(?) drift, but it seems like this would be a rare occurence.
• I'd like to go ahead and rename all block fields -> height. We discussed it at the last product design meeting of December and the follow up was to do some user research, but the general sentiment seemed to be that height >> block. I'll do this in a separate PR, but for now the new type introduced uses Event.Height.

[mitjat]

Thanks Andy! I mostly only have stylistic suggestions, which should be easy to address. The only exception is the very last comment, on the structure of the accounts_related_events table.

[mitjat]

Regarding the open questions from the PR description:

• The openapi spec calls consensus events ConsensusEvents but consensus transactions Transaction, which seems inconsistent. I'm in favor of renaming to Events, but we could also rename Transaction->ConsensusTransaction

I've been wanting to do the Transaction->ConsensusTransaction rename myself already :). I vote for that one, since in some senses, consensus is analogous to yet another (special) runtime. In general, I prefer saying ConsensusFoo over Foo, because I don't think it's obvious that Foo relates to consensus. This applies less to consensus specifics like governance voting, but definitely applies to generic things like events.

• Since we support filtering events by type, we need to have some mapping of all the valid event types. This used to be adjacent to the Event type the api types, but now that event types are autogenerated the mapping is separate from the ground truth. This could(?) drift, but it seems like this would be a rare occurence.

Yeah I think we're OK. We could add a comment? In #281, I argue we don't even need the full list, because checking for a valid enum input is maybe more work than it's worth. My opinion would be different if Go had better supprot for enums, or of oapi-codegen supproted them better. But really I don't care very much either way; I'm fine with a different solution to the one I'm proposing.

• I'd like to go ahead and rename all block fields -> height. We discussed it at the last product design meeting of December and the follow up was to do some user research, but the general sentiment seemed to be that height >> block. I'll do this in a separate PR, but for now the new type introduced uses Event.Height.

My intuition is to go the other way; in fact, I think I recently renamed height->block somehere, maybe in txs :). A block has a height, but a tx appears in a block (to which we happen to refer with a height). It's like how an event refers to a tx (well kinda ... tx_index really, because FKs are complicated there), not just to a hash or index., which are properties of the tx. We could rename to block_height? It's a little verbose. Anyway, let's talk during the next group meeting.

[aefhm]

Open questions:

• The openapi spec calls consensus events ConsensusEvents but consensus transactions Transaction, which seems inconsistent. I'm in favor of renaming to Events, but we could also rename Transaction->ConsensusTransaction

Agree with @mitjat on Transaction->ConsensusTransaction

• Since we support filtering events by type, we need to have some mapping of all the valid event types. This used to be adjacent to the Event type the api types, but now that event types are autogenerated the mapping is separate from the ground truth. This could(?) drift, but it seems like this would be a rare occurence.

I'm also okay with a comment.

• I'd like to go ahead and rename all block fields -> height. We discussed it at the last product design meeting of December and the follow up was to do some user research, but the general sentiment seemed to be that height >> block. I'll do this in a separate PR, but for now the new type introduced uses Event.Height.

I can go either way. Probably also defer to block.

[mitjat]

Looking good! Thank you!