refactor: Remove gogoproto yaml annotations (#409)

[ruhatch]

Description

Remove gogoproto yaml annotations.

Closes: #409

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[codecov]

Codecov Report

Merging #513 (fd18032) into master (4e3666b) will not change coverage.
The diff coverage is n/a.

❗ Current head fd18032 differs from pull request most recent head 95ae713. Consider uploading reports for the commit 95ae713 to get more accurate results

@@           Coverage Diff           @@
##           master     #513   +/-   ##
=======================================
  Coverage   77.51%   77.51%           
=======================================
  Files         100      100           
  Lines       12755    12755           
=======================================
  Hits         9887     9887           
  Misses       2276     2276           
  Partials      592      592           

Flag	Coverage Δ
experimental-codecov	77.51% <ø> (ø)
stable-codecov	68.29% <ø> (ø)

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

[technicallyty]

just curious - why do some fields have this addition while others dont?

[clevinson]

Historically this was about multiple word fields, and ensuring yaml encoding used snake-case instead of camel-case.

[clevinson]

I'm actually doing some further digging into edge cases and how this works here, as I'm suspicious there may be some strange change in behavior as previously things might have been json serialized as camel case...

[clevinson]

Looks good! @ruhatch is there a reason we're adding json_name in regen ledger, but not in the SDK? I'm looking at cosmos/cosmos-sdk#9780 as a corollary to this work, but didn't see any json_name tag additions in that PR.

[clevinson]

So digging into it a little more... I'm not actually sure if we need json_name field explicitly set at all, or what benefit we get from that?

Most of the time when we marshal/unmarshal (at least in the SDK), we're using jsonpb, and serializing using the original proto field name (we do this by setting the Marshaler.OrigName to true). Because of this, all serialization/deserialization using jsonpb should already work as expected and correctly parse/serialize as the field name (not the camelCase version).

One side note- we actually don't use the codec marshaler when creating the template JSON in our regen gen-batch-json cli command (I'll file an issue for this shortly).

By explicitly setting json_name here, we force any proto deserializers to fail when parsing camelCase fields, which actually goes against the standard behavior of proto as described in the language guide:

Parsers accept both the lowerCamelCase name (or the one specified by the json_name option) and the original proto field name.

If there's a specific reason for us wanting to fail on parsing camelCase JSON, then I think we should keep the tags. But otherwise I think adding the explicit json_name tags is just yet another thing to remember and maybe we should just drop it entirely, relying instead on the fact that we're already setting Marshaler.OrigName = true in the jsonpb codec.

[ruhatch]

Looks good! @ruhatch is there a reason we're adding json_name in regen ledger, but not in the SDK? I'm looking at cosmos/cosmos-sdk#9780 as a corollary to this work, but didn't see any json_name tag additions in that PR.

Okay, interesting! I need to check whether the new yaml library (which is only used in one place), will use the correct kind of JSON serialization or not.

I'll remove those tags!

[likhita-809]

lgtm