Migrate Minting module from Layer 2 module to Token Module and Refactor Token Module Structure

[kmlbgn]

Description

The current structure of the token module is problematic due to its fragmented approach. The Alias registrar uses the token symbol as a unique identifier and stores an array of denoms under the DenomToken prefix, while the Rate registrar uses denom as a unique identifier. This discrepancy creates unnecessary complexity and potential conflicts, particularly because the Alias registrar allows multiple denoms to be associated with a single symbol, which can interfere with the Rate registrar's operations. The two registrars do not interact or check consistency with each other, leading to a risk of incorrect information being displayed on the frontend. Additionally, there is no mechanism to track the total supply of all tokens within the current structure.

Expected Behaviour

• Consolidate the Alias registrar, Rate registrar, and Minting module into one cohesive data structure to store all relevant metadata of any token in KIRA (e.g., multistaking, aliases, minting details), cf Proto section below.
• Use denom as the unique identifier
• Implement a mechanism to track the total supply of all tokens within the unified structure.
• Ensure that parameters can be modified by the appropriate entity: governance should manage parameters related to multistaking, rates, and some minting parameters, while owners should control other specific minting parameters.
• Rename fee_payments to fee_enabled
• Rename stake_token to stake_enabled
• Rename invalidated to inactive
• Rename fee (from the minting module) to minting_fee
• Rename metadata to nft_metadata
• Rename hash to nft_hash
• supply_cap must allow value 0 to be set at first, which corresponds to infinite supply (no cap). However, it should not be possible to EDIT value to 0 since edition can only decrease supply.
• Add owners_disabled boolean for disabling editing for owners-only parameter (gov do not loose editing rights)
• Implement logic to sanitize adr43-only and adr20-only parameters. For instance, if adr43 is chosen, decimals becomes empty regardless of what users have set or any other explicit value.
• Owners Object must have the same structure as Controllers Object (cf issue Missing Controllers Blacklisting Flags in DApp Create and Upset proposal CLI  #667 which must be resolved)
• Prohibit Usage of Character _ in Unique Network Identifiers #670 should be resolved

Proto example

NAME	TYPE	CONDITIONS	EDITABLE BY	DESCRIPTION
token_type	string		None	adr20 for fungible token or adr43 for NFT
nft_metadata (adr43 only)	string		None	Address to a JSON file with a metadata. (The exact format of the metadata can be found in the https://docs.opensea.io/docs/contract-level-metadata)
nft_hash (adr43 only)	string		None	Hash of the metadata for authenticity
denom	string	UNIQUE 3-8 chars (a-z)	None	Full denom of the token, min 3 and max 8 lowercase alphabetic characters only (a-z). e.g. ap_kirabridge_btc or class identifier (can NOT be changed). Or class identifier in case of NFT.
decimals (adr20 only)	uint64	0-255	None	Number of currency decimals in the base of 10. For example value 3 would imply that the smallest unit of currency in it's default denomination would be 0.001
name	string	UNIQUE	Gov	Full, explicit name of the currency, eg. Bitcoin
symbol	string	UNIQUE 3-8 chars (A-Z)	Gov	The currency ticker or otherwise short abbreviation of a "single" token in its default denomination. For example: KEX, ETH, BTC, DOT, ATOM ....
icon	string	max 256 chars	Both	URL to .SVG image representing currency or network logo
description	string	max 512 chars	Both
website	string	max 256 chars	Both
social	string	max 256 chars	Both
supply_cap	string	max 2^256 - 1 (can ONLY be DECREASED, but not below current existing circulation supply)	Owners	Maximum supply that can be issued for this token. If set to 0, supply is infinite.
minting_fee	string		Owners	Cost of minting 10^decimals per X ukex, if set to 0 only owner can mint new tokens, if set to value other then 0 anyone can.
owners	Owners Object		Owners	Address, role or application name allowed to modify token’s editable parameters
owners_disabled	bool		Owners	When set to true, disables any further edits to parameters that were editable by the owners list. Once set to true, this action is irreversible.
inactive	bool		Gov	Indicates the inactive status of a token. If true, the token is marked as inactive for network interactions.
fee_rate	float		Gov	Sets the exchange rates for whitelisted tokens in terms of KEX.
fee_enabled	bool		Gov	Determines if a given token can be used to pay transaction fees on the KIRA Network.
stake_cap	float		Gov	Sets the maximum percentage of staking rewards that a given token is entitled to receive from a staking pool.
stake_min	uint64		Gov	Sets the minimum amount per delegations and undelegations for a given token to prevent a dust spam attack.
stake_enabled	bool		Gov	Determines whether or not a specific token can be used as collateral by delegators on the KIRA Network.

[kiragpg]

For last two ones, will take care of while handling those tasks directly.

- Owners Object must have the same structure as Controllers Object (cf issue Missing Controllers Blacklisting Flags in DApp Create and Upset proposal CLI  #667 which must be resolved)
- https://github.com/KiraCore/sekai/issues/670 should be resolved