Investigate (showcase) some design tweaks around Validation/Execution contexts

[Farhad-Shabani]

Related to: #325

Description

This PR aims to suggest possible ways to refactor ValidationContext/ExecutionContext for improved maintainability and intended to make the design more accessible to implementers.

Overall, two ideas have been incorporated into this PR (applied to some parts as a showcase), each of which could be investigated and implemented separately:

1. Recategorise ValidationContext and ExecutionContext methods under the below traits/groups
   (note that the exact placement of some methods may need to be discussed)

• trait HostContext bonded by Router
  Provides a minimal set of interfaces that must be provided by an IBC-enabled blockchain. It contains methods that read or write a host state BUT are not accessible through the IBC path from the key-value store and also includes operational methods.
  Note that this trait is very similar to the ADR-5 defined Host-based API

• trait ReaderContext bonded by HostContext
  Provides methods that enable access to states that can be retrieved from the key-value stores through the IBC path.

• trait KeeperContext bonded by ReaderContext
  Provides methods that enable setting states in a key-value store and performed via the IBC path.

• trait EventLogger & MsgLogger
  Provides event emitting and message logging facilities (read & write)

2. Separate the validate and execute methods from the validation/execution context and place them under two distinct pub(crate) ValidationHandler<Msg> and pub(crate) ExecutionHandler<Msg> interfaces.
   These traits have been implemented (Blanket) for each message type for contexts implementing ReaderContext and KeeperContext.

---

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

[plafer]

1. Recategorise ValidationContext and ExecutionContext methods under the below traits/groups
   (note that the exact placement of some methods may need to be discussed)

I think we should make big API changes like this based on feedback from users, and/or solving specific problems; otherwise we're incurring costs on the users (for keeping up with the breaking changes) for no clear reason. It is not clear to me how this new API benefits the user; specifically what is an example of a chain where the current API is restraining, and that it would be solved by this change?

2. Separate the validate and execute methods from the validation/execution context and place them under two distinct pub(crate) ValidationHandler and pub(crate) ExecutionHandler interfaces.
   These traits have been implemented (Blanket) for each message type for contexts implementing ReaderContext and KeeperContext.

validate and execute should simply be made free functions. The reason to remove them from Validation/ExecutionContext is that we only want to have methods in a trait if it could benefit the users to change the implementation, which is not the case for validate() and execute().