chore: ics29 error returns on fee validation

[damiannolan]

Description

• Return errors immediately as opposed to appending them

closes: #1234

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov-commenter]

Codecov Report

Merging #1235 (ba2196c) into main (311379f) will decrease coverage by 0.05%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##             main    #1235      +/-   ##
==========================================
- Coverage   80.05%   80.00%   -0.06%     
==========================================
  Files         166      166              
  Lines       11910    11906       -4     
==========================================
- Hits         9535     9525      -10     
- Misses       1914     1918       +4     
- Partials      461      463       +2     

Impacted Files	Coverage Δ
modules/apps/29-fee/types/fee.go	69.38% <25.00%> (-13.64%)	⬇️

[seantking]

I think we should leave this as is. In the case that more than one fee is invalid it would be good to include that in the error message.

I left a comment on fedes comment also : #276 (comment)

[crodriguezvega]

Yes, I also agree that we should leave it as is. I think it's better UX when you get error messages for all the things that you might have wrong at once, instead of executing each time the command and getting only the next error message.

[damiannolan]

Sounds good, in which case I'll close this PR and the issue!

[colin-axner]

My only concern with the agreed upon decision is that this is not how the SDK functions. The SDK does not batch up all errors in a message execution. Given that this error appending is self-contained in fee.Validate(), it seems fine, although I have a slight preference for not appending the errors. This error should be returned before a transaction is broadcasted so fixing errors one at a time seems simpler