feat(x/tx): Support gogo registry in Textual

[amaury1093]

Description

Closes: #14647

---

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)

[amaury1093]

I manually tested this the following way:

• Apply the changes here to activate Textual
• However, DON'T add the two lines in app_v2.go

	_ "cosmossdk.io/api/cosmos/bank/v1beta1"
	_ "cosmossdk.io/api/cosmos/crypto/secp256k1"

• run the app, make sure Textual txs pass

[amaury1093]

Converting to draft, let's wait for #15322 first

[amaury1093]

R4R again using #15322 Unpack

[JimLarson]

Here and below for similar converters - I'm quite confused by this. Don't we know that Any, Duration, etc, are in fact registered?

[amaury1093]

The fact that we import google.golang.org/protobuf/types/known/{any,duration...}pb indeed guarantees that Any, Duration are registered.

However, when they are nested in another message that's not registered, then they are dynamically created using dynamicpb. Consider a custom Msg, suppose it's only registered in gogo, and not in protov2:

message MsgCustom {
  google.protobuf.Any a = 1;
}

Then when Textual receives this message, it sees MsgCustom and will use dynamicpb to generate the whole proto.Message, including the nested field.

[amaury1093]

We currently use dynamicpb.NewMessageType to do this. We could consider writing our own dynamicpb.NewMessageTypeV2 that uses known types when generating a field with a known name. I'm not sure if that would be more helpful or confusing though.

Created a new issue: cosmos/cosmos-proto#104

[JimLarson]

Thanks for the explanation. It would be nice if we didn't have to complicate the textual code for this, but I don't know enough to second-guess the choices you've made here.

[facundomedica]

LGTM, ty Amaury for the detailed walkthrough 🙏

[JimLarson]

In the case of a dynamicpb.Messge, this function and its brothers need to check that the dynamic message has an appropriate message name, not just one that has fields of the right name and type. (We could argue that the name was checked when we dispatched here, but it should be easy to check in this function.)

Even better, how about a single function coerceToMessage(givenMsg, desiredMsg proto.Message) error that initializes a given desiredMsg (presented as a protov2 concrete message), fast-paths the case where givenMsg is a protov2 concrete message of the same type, for a dynamicpb it checks that the names match then uses proto reflection to initialize the fields of desiredMsg, and otherwise throws an error. This should be much less error-prone and reduce the proliferation of dynamicpb everywhere.

[amaury1093]

That's a good suggestion, thanks. I applied it in fbe2ce6, and the code looks less scattered.

I'll see about moving coerceToMessage to cosmos-proto.