Features/add module install fee

[Kayanski]

This PR aims at adding a fee on module installation for module creators to monetize their creations

TODO

• Add a monetization smart query on Version Control
• Remove dangling monetization references when last module version is removed

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	2af3182
Status:	✅  Deploy successful!
Preview URL:	https://64ed38be.contracts-egs.pages.dev
Branch Preview URL:	https://features-add-module-install.contracts-egs.pages.dev

View logs

[codecov]

Codecov Report

Merging #358 (2af3182) into main (51988c1) will increase coverage by 0.0%.
The diff coverage is 95.0%.

Impacted Files	Coverage Δ
packages/abstract-core/src/core/manager.rs	36.1% <ø> (ø)
contracts/native/module-factory/src/commands.rs	96.7% <88.2%> (-0.5%)	⬇️
contracts/account/manager/src/commands.rs	95.0% <88.8%> (+<0.1%)	⬆️
contracts/native/version-control/src/commands.rs	97.3% <93.6%> (-0.2%)	⬇️
contracts/native/account-factory/src/commands.rs	94.5% <100.0%> (ø)
contracts/native/version-control/src/contract.rs	97.2% <100.0%> (+<0.1%)	⬆️
contracts/native/version-control/src/queries.rs	96.2% <100.0%> (+<0.1%)	⬆️
...ckages/abstract-core/src/native/version_control.rs	82.8% <100.0%> (+3.5%)	⬆️
packages/abstract-core/src/objects/module.rs	86.0% <100.0%> (-0.6%)	⬇️
packages/abstract-sdk/src/apis/version_registry.rs	93.7% <100.0%> (+5.2%)	⬆️

... and 1 file with indirect coverage changes

[adairrr]

Would we want to check and remove a potentially dangling monetization configuration when removing a module?

[Kayanski]

Would we want to check and remove a potentially dangling monetization configuration when removing a module?

As we do not store the monetization object for a specific module version, this is not really possible, as we don't know which versions can still be registered and that need the monetization object.

[CyberHoward]

Could that query that's mentioned in the description be added? Well be required for front-end stuff

[Kayanski]

Could that query that's mentioned in the description be added? Well be required for front-end stuff

2 possibilities. Either we do a separate query or we return the monetization in the current modules query. I prefer having it in the existing module query, inside a config object that is not exhaustive

[CyberHoward]

Could you elaborate on why you prefer it?

[Kayanski]

Could you elaborate on why you prefer it?

Because we can group the queries to the module contract, no need to ask it multiple time about information.
You ask for a module and you get your monetization configuration
Moreover, if you want to add more configuration to the mix, we don't have to create a new message variant everytime,

[CyberHoward]

Could you elaborate on why you prefer it?

Because we can group the queries to the module contract, no need to ask it multiple time about information. You ask for a module and you get your monetization configuration Moreover, if you want to add more configuration to the mix, we don't have to create a new message variant everytime,

Sure, so something like

ModuleResponse {
  module: Module,
  monetization: Monetization,
}

?

[Kayanski]

Could you elaborate on why you prefer it?

Because we can group the queries to the module contract, no need to ask it multiple time about information. You ask for a module and you get your monetization configuration Moreover, if you want to add more configuration to the mix, we don't have to create a new message variant everytime,

Sure, so something like

ModuleResponse {
  module: Module,
  monetization: Monetization,
}

?

Yes or

	pub struct ModuleResponse{
		pub info: ModuleInfo,
		pub reference: ModuleReference,
		pub config: ModuleConfig
	}

	#[non_exhaustive]
	pub struct ModuleConfig{
		pub monetization: ModuleMonetization
	}

[CyberHoward]

Could you elaborate on why you prefer it?

Because we can group the queries to the module contract, no need to ask it multiple time about information. You ask for a module and you get your monetization configuration Moreover, if you want to add more configuration to the mix, we don't have to create a new message variant everytime,

Sure, so something like

ModuleResponse {
  module: Module,
  monetization: Monetization,
}

?

Yes or

	pub struct ModuleResponse{
		pub info: ModuleInfo,
		pub reference: ModuleReference,
		pub config: ModuleConfig
	}

	#[non_exhaustive]
	pub struct ModuleConfig{
		pub monetization: ModuleMonetization
	}

yup, great suggestion

[Kayanski]

Met you in the middle there