Refactor error system

[DaviRain-Su]

Closes: #164

Description

---

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).

[DaviRain-Su]

Do you have a better description of the error?

    /// Ics04 channel error(`{0}`)
    Ics04Channel(channel_error::Error),
    /// invalid port identifier `{context}` error(`{validation_error}`)
    InvalidPortId {
        context: String,
        validation_error: ValidationError,
    },
    /// invalid channel identifier `{context}` error(`{validation_error}`)
    InvalidChannelId {
        context: String,
        validation_error: ValidationError,
    },

[plafer]

Note: hopefully our solution here also addresses #23. I'm still thinking about how to make everything work together (logs discarded on error issue, no_std support, error sources, small number of Error variants if possible, etc)

EDIT: Actually #23 fixed by the new ValidationContext: logs are no longer returned, but rather given to the context with log_message().

[DaviRain-Su]

I do not know if my understanding of this is in line with the requirements

[plafer]

Having thought about this some more, I like the direction this PR is taking. IMO what's left to be done is:

1. Remove all unused errors such as this one. Once this is done, we can additionally look to combine redundant errors.
2. "Roll our own backtrace", as @hu55a1n1 suggested. We should make sure to use the same convention everywhere, as you started doing here: <error message>: {0} (for when the error argument is another Error). When std::error::Error makes it into core, we can start using thiserror.
3. Make sure there's a Error::Other variant for host methods to use. This PR is getting big enough, we can change host functions in another PR.

[DaviRain-Su]

When std::error::Error makes it into core, we can start using thiserror
Currently thiserror can not be used in no_std, thiserror::Error I think the implementation of this macro can not be used in the current no_std environment, and the current use of displaydoc I think similar to thiserror except that there is no error backtrace, but here we have implemented std::error::Error.

#[cfg(feature = "std")]
impl std::error::Error for Error {
    fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
        match &self {
            Error::InvalidHeader { error: e, .. } => Some(e),
            Error::InvalidTendermintTrustThreshold(e) => Some(e),
            Error::InvalidChainIdentifier(e) => Some(e),
            Error::InvalidChainId { error: e, .. } => Some(e),
            Error::InvalidRawHeader(e) => Some(e),
            Error::Decode(e) => Some(e),
            Error::TimestampOverflow(e) => Some(e),
            _ => None,
        }
    }
}

[DaviRain-Su]

when thiserror support we just add #derive[thiserror::Error] can remove below this.

#[cfg(feature = "std")]
impl std::error::Error for Error {}

[plafer]

Requested additional input from @blasrodri; let's hold until then

[blasrodri]

I like the idea of getting rid of flex-error. Plus, the naming of the errors has become more descriptive, and do not assume that the developer is so acquainted with the different ics. I'm not sure if thiserror is needed at all - would be nice to see a use case that's not currently covered with the current implementation. Seems like something that the library consumers would like to have.

Overall, I think this PR reflects the goals of #164 .

[plafer]

Thank you for this amazing work; we're getting really close to the finish line! 😃

[plafer]

Awesome work :)

[DaviRain-Su]

Awesome work :)

thx guys