upgrade_client: Make TYPE_URL public

[kevinji]

Closes: #XXX

Description

This makes upgrade_client::TYPE_URL public to match the visibility of all other TYPE_URL constants, and makes it easier to access outside of the crate.

---

PR author checklist:

• Added changelog entry, using unclog.
• Added tests.
• Linked to GitHub issue.
• Updated code comments and documentation (e.g., docs/).
• Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

• Reviewed Files changed in the GitHub PR explorer.
• Manually tested (in case integration/unit/mock tests are absent).

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (20d682f) 72.85% compared to head (45f158b) 72.85%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #588   +/-   ##
=======================================
  Coverage   72.85%   72.85%           
=======================================
  Files         126      126           
  Lines       15705    15705           
=======================================
  Hits        11442    11442           
  Misses       4263     4263           

Impacted Files	Coverage Δ
...s/ibc/src/core/ics02_client/msgs/upgrade_client.rs	84.53% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[Farhad-Shabani]

Thanks for pointing out this discrepancy.

Considering the existing type_url interface for each message type, it sounds like we should take the opposite approach and make others pub(crate) to improve encapsulation and prevents confusion for callers, as some use type_url() and others might import TYPE_URL const.

Based on a previous review, it appears that TYPE_URL is typically used for converting a domain message to Any, which accepts a String type. For this usage as well, calling the type_url() method is better.

[plafer]

@kevinji do you have a use case for needing the TYPE_URL? As Farhad mentioned, we were instead going to move in the direction of making all the other TYPE_URL private.

[kevinji]

Nope I didn't know that tx_msg::Msg existed, so closing in favor of using that interface.

[Farhad-Shabani]

Nope I didn't know that tx_msg::Msg existed, so closing in favor of using that interface.

👍🏻
by the way, I opened #597 to deal with it at the appropriate time

[plafer]

Nope I didn't know that tx_msg::Msg existed, so closing in favor of using that interface.

Could you link to an example snippet where you need the TYPE_URL or tx_msg::Msg::type_url? I was hoping to get rid of tx_msg::Msg too.

[kevinji]

It's essentially the same use case as #586 as I'm currently directly using MsgEnvelope in one of my types:

                match msg_envelope {
                    // ICS2 messages
                    MsgEnvelope::Client(ClientMsg::CreateClient(domain_msg)) => domain_msg.to_any(),
                    MsgEnvelope::Client(ClientMsg::UpdateClient(domain_msg)) => domain_msg.to_any(),
                    MsgEnvelope::Client(ClientMsg::UpgradeClient(domain_msg)) => {
                        domain_msg.to_any()
                    }
                    // ...
                }

I do plan to switch these to be backed by the raw types instead, per the discussions we've had, but for now I'm using tx_msg::Msg to help with serialization.