refactor!: remove legacyamino functions

[tac0turtle]

Description

second attempt at removing amino usage in the sdk in favor of the automated version

This pr removes:

• Grpc decode aminotxs since this is no longer supported

ref #17775

---

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
• run make lint and make test
• 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)

[alexanderbez]

Pretty substantial PR, but from the looks of it, it seems good to me.

[julienrbrt]

Why do we delete this actually?
Wasn't it added per community request?

[kocubinski]

I think I agree; we can still encode to amino JSON via the encoder in x/tx or is this talking about a different amino format? (I remember something about a binary amino format).

Instead maybe keep the messages/services and have the decode service return an error since this is what we're dropping support for.

[tac0turtle]

technically this doesn't work for modules that dont registerlegacyamino, so we have a bit of a discrepancy on support here. I can look at adding back the encode but decode id just remove.

[julienrbrt]

Shouldn't this stay as well? cc @kocubinski

[kocubinski]

I really think we should find a way to keep these tests; even if that means moving the (now) legacy amino json encoder dependency into a _test namespace or package.

They are asserting that the amino json encoder has equivalent output to the legacy one which could prove valuable if issues arise down the road.

[tac0turtle]

i can look at registering the amino types needed for this test in the test but the modules wont be reverted. Modules need to move forward and breaking things is part of it. Otherwise we will never be able to move forward

[kocubinski]

I see what you mean. I'm not sure how this would work right exactly right now, but another possibility is to obtain a "golden file" comprising the output of passing the proto types generated through rapidproto at a particular seed (doesn't matter what).

Since this golden file, made in good faith, has the same output as legacy amino json encoder we could delete the encoder code and all the wiring for it but still assert the correctness of the x/tx one.

[kocubinski]

Also the golden file is committed to source control.

[kocubinski]

I think we should retain the generative tests, lmk if you need help generating the golden file.

[tac0turtle]

closing this for now, would like to pair it with another issue