imp: remove order_matches from ChannelEnd impl

[tuantran1702]

Closes: #394

Description

Remove the order_matches method, refactor the current usage of order_matches to use match statements instead.

---

PR author checklist:

• Added changelog entry, using unclog.
• 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).

[tuantran1702]

Hi @Farhad-Shabani, please take a look at this PR. Thank you.

[rnbguy]

Thanks @tropicaldog for the PR 🙏

Last nit before I approve the PR !

[rnbguy]

Awesome ! Thanks ✨

[codecov]

Codecov Report

Attention: 41 lines in your changes are missing coverage. Please review.

Comparison is base (49e66de) 66.58% compared to head (15a215b) 66.53%.

Files	Patch %	Lines
...core/ics04-channel/src/handler/timeout_on_close.rs	36.36%	21 Missing ⚠️
ibc-core/ics04-channel/src/handler/recv_packet.rs	60.71%	11 Missing ⚠️
ibc-core/ics04-channel/src/handler/timeout.rs	72.72%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1095      +/-   ##
==========================================
- Coverage   66.58%   66.53%   -0.06%     
==========================================
  Files         204      204              
  Lines       20519    20532      +13     
==========================================
- Hits        13663    13661       -2     
- Misses       6856     6871      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Farhad-Shabani]

Thank you @tropicaldog for handling this PR and @rnbguy for the review. Just wanted to make a point:

We consider Order::None as an invalid order type, explicitly disallowing the creation of a channel with this order type. This validation aligns with the check conducted in ibc-go.

Therefore, if our IBC handlers encounter a channel end with an order of None during the retrieval process from a store, it signals a potential manipulation in the storage. In such cases, I believe it should be treated as an error.

[rnbguy]

Thanks @tropicaldog ! Just a nit request. Then we are ready to merge 🙂

[rnbguy]

Nice work, @tropicaldog 🚀

Thanks for the first contribution 💜

[Farhad-Shabani]

Thank you for the fix! 👌🏻