Refactor WeightToFee to include ProofSize

[valentinfernandez1]

This PR introduces an update to the WeightToFee struct, addressing the changes discussed in issue #169. The update aligns the struct with the latest version included in release v0.9.40, which incorporates the following trait:

pub trait WeightToFee {
/// The type that is returned as result from calculation.
    type Balance: BaseArithmetic + From<u32> + Copy + Unsigned;

    /// Calculates the fee from the passed `weight`.
    fn weight_to_fee(weight: &Weight) -> Self::Balance;
}

The implementation of this functionality draws heavily from the implementation provided by statemine (now called asset-hub). However, the FeePolynomial struct and some Trait functions that are used in statemine implementation are not available for v0.9.40. To address this, a custom trait called WeightCoefficientCalc has been implemented, which facilitates the necessary calculations.

pub trait WeightCoefficientCalc<Balance> {
    fn saturating_eval(&self, result: Balance, x: Balance) -> Balance;
}

impl<Balance> WeightCoefficientCalc<Balance> for WeightToFeeCoefficient<Balance>
where
    Balance: BaseArithmetic + From<u32> + Copy + Unsigned + SaturatedConversion,
{
    fn saturating_eval(&self, mut result: Balance, x: Balance) -> Balance {
	let power = x.saturating_pow(self.degree.into());

	let frac = self.coeff_frac * power; // Overflow safe.
	let integer = self.coeff_integer.saturating_mul(power);
	// Do not add them together here to avoid an underflow.

	if self.negative {
		result = result.saturating_sub(frac);
		result = result.saturating_sub(integer);
	} else {
		result = result.saturating_add(frac);
		result = result.saturating_add(integer);
	}

	result
    }
}

This implementation can be easily switched to use FeePolynomial after upgrading the substrate version to v0.9.42 or above.

---

Note: I plan to include additional tests to ensure that this works as intended specially on write heavy extrinsics, but feel free to leave your feedback on this change in the mean time.

closes #168
closes #169

[kalaninja]

I've noticed a comment referencing kusama and took a closer look. Is it ok that we are using constants from kusama_runtime_constants? I think trappist should be referencing those of polkadot.

[kalaninja]

I think you can be more specific here and say that it's "Overflow safe" because coeff_frac is strictly less than 1.

[valentinfernandez1]

I've noticed a comment referencing kusama and took a closer look. Is it ok that we are using constants from kusama_runtime_constants? I think trappist should be referencing those of polkadot.

This should be discussed since it's also part of trappist v0.9.37 I don't know the reason why it was added initially maybe @stiiifff can clarify the reasoning behind it.

[stiiifff]

nitpick: changes to this files probably shouldn't be part of this PR.

[stiiifff]

I've noticed a comment referencing kusama and took a closer look. Is it ok that we are using constants from kusama_runtime_constants? I think trappist should be referencing those of polkadot.

This should be discussed since it's also part of trappist v0.9.37 I don't know the reason why it was added initially maybe @stiiifff can clarify the reasoning behind it.

@valentinfernandez1 @kalaninja The intention there was/is to use the same numbers as Kusama for things like existential deposit, deposit fees, and currency-related constants (i.e. the chain's native token, HOP, is mirroring the KSM token for decimals, total emission).

[stiiifff]

Looks good, @valentinfernandez1 let's get the build fixed, and then LGTM.