feat: create 08-wasm-light-clients structure

[gjermundgaraba]

Description

closes: #7595

From the ibc-go devs I am looking mostly for structure feedback. @srdtrk can provide the rust specific feedback.

I played around with a few different options for folder structure, but ended up with the current structure, which has the main benefit of being close to everything light clients in the repo. An alternative I also tried was a root level "rust" folder, which also works, but the naming of the sub-folders felt more natural when it was under the light-clients folder.

Happy to hear other ideas and other naming suggestions in general.

This PR just aims to set up the structure to start moving code over from the Union light client repo. The 08-wasm light client that is there now is essentially a "mock" light client that will accept anything and always return true.

I also tried to move the api_contract into proto files to get them generated - and it is possible. It does require quite a bit of custom handling, especially for the rust generated code. In the end, I decided it might not be worth it due to both implementation really only needing JSON/serde. We could do this at a later point if we think it might be useful to also publish that contract api as a rust crate for easier implementation.

---

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 the 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 and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/).
• Added relevant godoc comments.
• Provide a conventional commit message to follow the repository standards.
• Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
• Re-reviewed Files changed in the GitHub PR explorer.
• Review SonarCloud Report in the comment section below once CI passes.

[srdtrk]

Looks good. I think this needs to have it's own feature branch since it contains only a template at the moment

[srdtrk]

If we don't want to publish and continue to maintain this, we could also use tonic's build macros instead of generating the code ourselves. This also hides all the generated code (similar to how alloy's sol macro works). But I'm fine with this as is.

I understand why we need this, but we should either use ibc-proto in the future, or move ibc-proto here. In the mean time, tonic macros could be used if it works...

[gjermundgaraba]

My thinking was that this should could replace ibc-proto eventually. Tonic is an option, but to be honest I don't love hidden generated code because it makes it a lot harder to understand underlying types and what is really going on (too much magic for my taste).

[srdtrk]

Instead of using *, you probably want to point to the exact directory instead since this is a multi language repo.

Suggested change

	"contracts/*",
	"packages/*",
	"contracts/ethereum-light-client",
	"packages/ibc-go-proto",

[gjermundgaraba]

It's a multi language repo, but the folder we're in is for the rust code. If we suddenly add anything there, builds will fail and then we can adjust, no?

[srdtrk]

This PR should have it's own feature branch and not be merged directly to feat/ibc-eureka in my opinion

[gjermundgaraba]

If possible to get things merged in smaller increments, it will be easier than having to maintain yet another feature branch. I would prefer to avoid another branch if smaller PRs can do the job

[bznein]

If possible to get things merged in smaller increments, it will be easier than having to maintain yet another feature branch. I would prefer to avoid another branch if smaller PRs can do the job

Having been dealing with multiple feature branches for a while now, I 100% agree!

[srdtrk]

I think we should enforce documentation in all public API in this crate like we do in ibc-go (since people and future devs might want to read). We can also add stricter linting as follows:

Suggested change

	pub mod contract;
	#![deny(clippy::nursery, clippy::pedantic, warnings, missing_docs)]
	pub mod contract;

[gjermundgaraba]

Sure! I will do that in a separate task: #7604

[srdtrk]

why don't we have a build script that uses cosmwasm optimizer? I think this is the only one we need since we want reproducible builds

[gjermundgaraba]

I was planning to add that when this is together with e2e integration, but it does take quite a bit longer to run, and it is not strictly necessary for CI right now.

[gjermundgaraba]

Looks good. I think this needs to have it's own feature branch since it contains only a template at the moment

I'm keen to hear other people's opinion on this, but my personal take is that I would love to avoid feature branches as much as possible unless there is a very good reason to keep the code out of main or feat/ibc-eureka. I have tried to structure the work in such a way that it can be merged as smaller PRs and not break anything along the way. Getting things merged sooner and more often feels better than having a lot of feature branches all over the place.

[yihuang]

Do we need to include cosmwasm module to use this?
Or we just use the wasm runtime to execute the code, but not require the module?

[damiannolan]

There is a hard dependency right now on ibc wasm light clients with cosmwasm (through the 08-wasm go proxy module).

[gjermundgaraba]

As discussed, this is being moved to the solidity repo instead. PR will be opened there.
Epic also moved: cosmos/solidity-ibc-eureka#141