Remove support for ServiceMsgs TypeURLs

[amaury1093]

Summary

Should we still support ServiceMsg TypeURLs in txs in v0.43?

Terminology

1. Msg TypeURL, e.g. "/cosmos.bank.v1beta1.MsgSend"

This is the TypeUrl of a proto message when packed inside an Any. For example: we can pack bank.MsgSend in an Any in txs. We then have any.TypeURL == "/cosmos.bank.v1beta1.MsgSend".

2. ServiceMsg TypeURL, e.g. "/cosmos.bank.v1beta1.Msg/Send"

This is the TypeUrl of an ADR-031 Msg Service method name. In ADR-031, we simulate packing a ServiceMsg in an Any. We then have any.TypeURL == "/cosmos.bank.v1beta1.Msg/Send"

Notice the ServiceMsg TypeURL has 2 / (it defines a service method fully-qualified name) whereas a Msg TypeURL only has one / (it defines a proto message name).

Problem Definition

The SDK currently (as of v0.42) supports txs with both ServiceMsg TypeURLs (routed via Baseapp's msg_service_router) and concrete Msg TypeURLs (routed via the legacy handler). ADR-031's vision was to slowly deprecate Msg TypeURLs.

However, #9063 made a point that ServiceMsg TypeUrls (terminology 2 above) are not protobuf compliant. #9139 was created to deprecate them (more specifically: Baseapp's msg_service_router routes messages using the concrete Msg TypeURLs instead of the ServiceMsg one)

Currently, ServiceMsg TypeURL are still supported, but deprecated, in case some explorers/clients are already using ServiceMsgs.

But should we support&deprecate ServiceMsg TypeURLs in v0.43, or completely remove them?

ref: #9139 (review)

Proposal

Proposal 1: Completely remove ServiceMsg TypeURL support for v0.43.

With documentation, changelog, clear communication etc.

Pros:

• v0.43 will be protobuf-spec-compliant.
• ServiceMsg TypeURLs are not yet widely adopted, we can kill it before too many chains upgrade to v0.43.

Cons:

• Client-breaking change for v0.42->v0.43 upgrades.

Proposal 2: Keep ServiceMsg TypeURL support for v0.43, remove it later (e.g. v0.44).

With deprecation notice.

Pros:

• Leave time for v0.42 clients/explorers to adapt to this client-breaking change, thanks to deprecation notice.

Cons:

• Client-breaking change down the road, possibly many chains will already be using ServiceMsg TypeURLs.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[amaury1093]

I'm in favor of Proposal 1. There's gonna be client breaking changes anyway, so rather soon than later.

[amaury1093]

Proposal 1 is implemented in #9139