feat: generic structure through execution cycle

[s8sato]

Context

Tracking issue:

• #5356

This PR introduces an abstract structure applicable to executables, events, event filters, and permissions to streamline the execution cycle.

• No API changes are introduced at this stage.
• The iroha_tree::*::transitional submodules demonstrate the potential to replace the current structure.
• Partially bypasses existing logic behind the non-default prediction feature, enabling loop detection at trigger registration time (for non-Wasm executables).

Since I was unsure whether this change would be a viable atomic change until opening this PR, no RFC was written beforehand. Let's discuss it here.

Related Work

• Partially resolves the loop detection aspect of #5232
  • To fully implement loop detection, Wasm executables must statically declare the union of possible events: #5362
• Lays the groundwork for:
  • Trigger per transaction: #4937
  • Executing triggers as internal transactions: #4968

Migration Guide

• transitional submodules serve as interfaces between new and existing structures.
• Any future API changes will result from resolving and removing these transitional submodules.

---

Review Notes

classDiagram
%% note "This is a general note"
%% class Tree
%% class FuzzyTree
class StateView
class ReadSet
class ChangeSet:::prediction
class Event:::prediction
class Receptor:::prediction
class Permission
class Add
class BitOr

classDef prediction color:#f9f

%% FuzzyTree <-- Tree

%% Tree <|.. StateView
%% FuzzyTree <|.. ReadSet
%% Tree <|.. ChangeSet
%% Tree <|.. Event
%% FuzzyTree <|.. Receptor
%% FuzzyTree <|.. Permission

StateView <-- ReadSet : load()
Event <-- StateView : as_status()
Event <-- ChangeSet : as_status()
Permission <-- StateView : passes()
Permission <-- ChangeSet : passes()
Receptor <-- Event : passes()
Receptor .. Permission : same repr
ChangeSet <-- Receptor : triggers

Add <|-- ChangeSet : implements
BitOr <|-- Permission : implements

For the loop detection feature:

• Unit test: iroha_tree::state::tests::detects_event_loop
• Integration test: iroha::mod::triggers::not_registered_when_potential_event_loop_detected

The crate documentation provides an abstract:

iroha_tree

A transitional crate that might eventually be merged into other crates.

It aims to integrate executables, events, and event filters while enabling recursive trigger prediction in a static manner. The prediction is based on the union of possible execution paths, enabling pessimistic event loop detection.

Additionally, to maintain performance while enabling per-transaction triggers (#4937), it consolidates:

• Instructions into a single [ChangeSet] per transaction.
• (Data) events into a single [Event] per transaction.
• (Data) event filters into a single [Receptor] per trigger.
• Permissions, roles, and ownerships into a single [Permission] per validation.

iroha_authorizer

A crate enabling user-defined logic to authorize or reject executables and queries based on the authority’s permissions and ownerships.

This is a stripped-down version of the executor, focused solely on permission validation (#5357). It does not define or execute instructions.

Checklist

• [x] I've read CONTRIBUTING.md.
• [x] I've written unit tests for the code changes.
• [ ] All review comments have been resolved.
• [ ] All CI checks pass.

[s8sato]

Converted to draft because the second feature commit is no longer planned (now classified as Future Consideration).