refactor: improve custom instruction usage

[mversic]

Description

Linked issue

Closes #{issue_number}

Benefits

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

[DCNick3]

As far as I can see, this PR:

• adds a custom parameter and an empty file for custom permissions to the executor_custom_data_model test smartcontract
• removes Fail instruction; replaces its uses in tests with unregistering of a non-existent domain
• renames Custom instruction to CustomInstruction
• in addition to Instruction trait, adds BuiltInInstruction, allowing Instruction to be not sealed
• in addition to Query trait, adds a sealed BuiltInQuery trait, by analogy with the Instruction trait.
• makes it so that in smart contracts, only BuiltInInstruction and BuiltInQuery can be executed.

My guess that the main point of it is the last change: to not allow custom instructions to be executed from wasm. While I see how it's beneficial to prevent this for executor (it's kind of recursive otherwise), I am not sure that regular smart-contracts & triggers should be prohibited from doing so...

[mversic]

adds a custom parameter and an empty file for custom permissions to the executor_custom_data_model test smartcontract

that was an accidental leftover

removes Fail instruction; replaces its uses in tests with unregistering of a non-existent domain

this can now be expressed with a custom ISI

in addition to Query trait, adds a sealed BuiltInQuery trait, by analogy with the Instruction trait.

reverted, since as you point out it has no benefit

My guess that the main point of it is the last change: to not allow custom instructions to be executed from wasm. While I see how it's beneficial to prevent this for executor (it's kind of recursive otherwise), I am not sure that regular smart-contracts & triggers should be prohibited from doing so...

I tried initially but there were practical problems. Like I had to derive Decode/Encode, implement encode_as_instruction_box which depended on EnumRef. It was becoming a rabbit hole, but you raise a good point about smart contracts

[mversic]

@DCNick3 I agree it's quite unfortunate that this doesn't work from within smart contracts, but it's still an improvement. Like was previously possible, from within smart contracts user would have to convert instruction into CustomInstruction and then execute. I will open a ticket to explore this. Created #4784