refactor(stdlibs/std): re-organize gnoEvent struct

[r3v4s]

Closes #2002

Also related to #2001

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• [] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• [] Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.79%. Comparing base (6243b56) to head (bfe3538).
Report is 16 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2160      +/-   ##
==========================================
+ Coverage   54.63%   54.79%   +0.15%     
==========================================
  Files         583      583              
  Lines       78507    79110     +603     
==========================================
+ Hits        42895    43350     +455     
- Misses      32399    32487      +88     
- Partials     3213     3273      +60     

Flag	Coverage Δ
contribs/gnodev	23.81% <ø> (ø)
contribs/gnofaucet	15.31% <ø> (+0.85%)	⬆️
contribs/gnokeykc	0.00% <ø> (ø)
contribs/gnomd	0.00% <ø> (ø)
gno.land	62.54% <ø> (+0.52%)	⬆️
gnovm	59.97% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zivkovicmilos]

Looks great 💯

Thank you for applying the suggested changes from the original PR 🙏

[zivkovicmilos]

@r3v4s Can you pull in the latest master?

[r3v4s]

@zivkovicmilos @thehowl
Adding more metadata in event struct by default brings pros and cons.

Here is my new suggestion

1. Remove Type. I really can't find meaningful usage for this specified type data. (Perhaps Name would be more to determine which event)

2. Keep current pkgPath, Func, OrigCaller and prev. For observability I think these for values are least required ones.

3. PrevFunc is tricky. I wanted bring more observability only by just examining event datas, not bunch of other datas from another rpc end points. But if this is too much for general point of view, we can get rid of it.

[thehowl]

Okay, I've had a discussion with Milos with what to do here.

Essentially, I don't think there is a compelling case for adding PrevRealm nor PrevFunc. PrevFunc shouldn't be necessary (also I think it's buggy, but anyway); PrevRealm contains information which if it is really useful to the reader of the events, they can just be passed in as attributes. (That's the whole point of attributes).

Reading your last comment;

Here is my new suggestion

1. Remove `Type`. I really can't find meaningful usage for this specified `type` data. (Perhaps `Name` would be more to determine which event)

2. Keep current `pkgPath`, `Func`, `OrigCaller` and `prev`. For observability I think these for values are least required ones.

3. `PrevFunc` is tricky. I wanted bring more observability only by just examining event datas, not bunch of other datas from another rpc end points. But if this is too much for general point of view, we can get rid of it.

I tend to agree on 2. For 3, I don't think PrevFunc or PrevRealm are useful, so just scrap them.

Type: we can change it to name, but having worked with event systems like this in the past, I know it's useful. If you're using Go, it allows you to have the name parsed as a string, and the attributes as a json.RawValue; then switching what to unmarshal the RawValue depending on the value of the type.

We can change it to name; but I think Type is fine too.

This is how I see this PR right now:

• We can close, or:
• Change Type to Name; and please, bring it back to the top of the struct (and put attributes next to it, instead of at the bottom)