chore: reorganize data_model crates

[mversic]

• create new data_model directory (these are not wasm crates, they just have to be usable in no_std)
• move crates that are shared between iroha tests and wasm there
• follow up on perf: Directly provide payload to WASM entrypoints #5113 for triggers and smart contracts
• rework prelude imports for iroha_smart_contracts, iroha_trigger, iroha_executor

[nxsaken]

Why not samples as the root directory with libs and wasm inside? Also, it seems strange that iroha_multisig_data_model is in libs, while the rest of *_data_model are in samples (aren't all of them libs?)

[mversic]

Why not samples as the root directory with libs and wasm inside? Also, it seems strange that iroha_multisig_data_model is in libs, while the rest of *_data_model are in samples (aren't all of them libs?)

we need to recognize there are 3 categories of crates:

1. regular crates (residing in /crates)
2. wasm crates (built as cdylib)
3. glue crates (bridge between regular and wasm crates)

Additionally, there is a distinction between crates that we recommend for production (libs) and the ones that we use in our integration tests (samples).

I'm open to suggestions on how to organize

[nxsaken]

Having only one directory for the sample libraries indicates that there is nothing magical about iroha_multisig_data_model compared to the rest of the "glue" crates, that it's a plain old library crate that just happens to be a best-practice example.

How about just a README in the samples directory explaining that wasm contains sample executors, triggers and smart contracts (the fact that they are being tested can be mentioned, but I wouldn't frame it as their purpose), while libs contains satellite library code used by wasm artifacts. The README could mention that iroha_multisig_data_model is the recommended way to implement multisig in production, and that default_executor is the executor used by default.

I would categorize the crates like this:

1. regular crates (/crates)
2. samples that build on top of the regular crates (/samples)
   • library code (/samples/libs) for custom data models etc.
   • executable code (/samples/wasm) for the actual artifacts, potentially using the library code

[mversic]

Having only one directory for the sample libraries indicates that there is nothing magical about iroha_multisig_data_model compared to the rest of the "glue" crates, that it's a plain old library crate that just happens to be a best-practice example.

How about just a README in the samples directory explaining that wasm contains sample executors, triggers and smart contracts (the fact that they are being tested can be mentioned, but I wouldn't frame it as their purpose), while libs contains satellite library code used by wasm artifacts. The README could mention that iroha_multisig_data_model is the recommended way to implement multisig in production, and that default_executor is the executor used by default.

I would categorize the crates like this:

1. regular crates (`/crates`)

2. samples that build on top of the regular crates (`/samples`)
   
   * library code (`/samples/libs`) for custom data models etc.
   * executable code (`/samples/wasm`) for the actual artifacts, potentially using the library code

ok, I don't disagree, but I'd leave it for another PR. This will conflict with multisig PR