feat: generic structure through execution cycle

[s8sato]

Context

Tracking issue:

• Refactor Execution Cycle #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 Trigger that fires too often #5232
  • To fully implement loop detection, Wasm executables must statically declare the union of possible events: Wasm executable should declare the union of possible events #5362
• Lays the groundwork for:
  • Trigger per transaction: Per-transaction triggers #4937
  • Executing triggers as internal transactions: Record trigger execution as a transaction #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

Loading

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

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

[0x009922]

Side effect should probably not occur during the TryFrom conversion, which in all other ways is a pure data transformation.

Isn't critical though, but maybe it's possible to have some sort of "side-effect" node?

[0x009922]

Suggested change

	/// 0. Transaction: [register Carol]
	/// 0. Trigger execution: account created (Carol) -> mint roses for Carol
	/// 0. Transaction: [burn one of Carol's roses] ... Depends on the previous trigger execution
	/// 0. Block commit
	/// 1. Transaction: [register Carol]
	/// 2. Trigger execution: account created (Carol) -> mint roses for Carol
	/// 3. Transaction: [burn one of Carol's roses] ... Depends on the previous trigger execution
	/// 4. Block commit

[s8sato]

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

[s8sato]

This design breaks down the current all-in-one Action object into separate parts—the condition, the execution, and the mapping between them—to maximize reusability. For example, the "deposit to self" condition only needs a single global definition rather than one per trigger, and you don’t have to register the same execution component twice just because it’s invoked manually versus event-driven.

[s8sato]

This analysis of the pros and cons of the main commit matches about 60% of my own understanding. I intend to refine this analysis and, based on it, rewrite this commit as a separate PR.