[fix] #4082: Remove cloning for ISI and query execution in wasm

[mversic]

Description

I left Visit trait to work with references and have removed redundant cloning through other means. One of the reasons why I left it is so that we can keep calling mem::forget at the end of validation but also because it's just not necessary to take them by value

Linked issue

Closes #4082

Benefits

less cloning

Checklist

• I've read CONTRIBUTING.md
• I've used the standard signed-off commit format (or will squash just before merging)
• All applicable CI checks pass (or I promised to make them pass later)
• (optional) I've written unit tests for the code changes
• I replied to all comments after code review, marking all implemented changes with thumbs up

[Erigara]

Like this change, often cloning could be avoided when doing serialization.

[DCNick3]

I kind of don't like how fragile this approach is: any mismatch between the encode_as_* function implementation and the derived scale encodings (that can be easily created by accident when modifying some instructions, for example) would lead to hard-to-diagnose encoding issues. But I don't there's a way to resolve this that doesn't rely on macros, and we already have enough of those in iroha..

If we decide to go the macro way we can either:

• automatically derive the encode_as_* functions (keeping the approach used in this PR)
• automatically generate the sister *BoxRef structures with owned values replaced by references (following the approach suggested by @Erigara)

I think the second one will be easier to implement, especially seeing how heterogeneous the encode methods for instructions are due to different levels of nesting..

Another far-fetched idea w/o using macros is to somehow make instructions/queries cheaper to clone (for example, by moving out all the expensive objects like strings to arenas/bump allocators/...). I don't think those are worth the complexity they bring though.

[Arjentix]

any mismatch between the encode_as_* function implementation and the derived scale encodings (that can be easily created by accident when modifying some instructions, for example)

I don't think that could actually happen to us.
encode_as_* fallback to self.encode_to(), so changing internal fields won't break anything.
And while we keep this enums everything should be fine. Throwing back these enums would be a big change and we certunally catch such problems with encodings (at least because of autogenerated *Type enums).

[Arjentix]

I like it

[github-actions]

@BAStos525