feat: allow for different decimals between fee token and underlying

[kosecki123]

This PR adds extra variable called

feeToUnderlyingDecimalsScale with default 1e0

to accommodate the difference in decimals amount for fee token and underlying token (deposit / redeem amount).

setFeeToUnderlyingDecimalsScale added for owner to allow setting the scale.

[sirnicolaz]

@kosecki123 what's the plan with this FlatFeeCalculator? Are we gonna use it only for the REDD pool?
Otherwise, if the plan is to use it as a general fee calculator, maybe it would be better that the caller passes the scale to the _calculateFee function. In case we have another pool, then we don't need to deploy a new flat fee calculator.

alternatively we can keep it like this and redeploy a more general version later in case we have the need.

[kosecki123]

@kosecki123 what's the plan with this FlatFeeCalculator? Are we gonna use it only for the REDD pool? Otherwise, if the plan is to use it as a general fee calculator, maybe it would be better that the caller passes the scale to the _calculateFee function. In case we have another pool, then we don't need to deploy a new flat fee calculator.

alternatively we can keep it like this and redeploy a more general version later in case we have the need.

Depends on how you want to treat the fee calculators, as a shared deployed contract or per pool deployment. Either way we need to have the scaler.

I like the idea of passing the scale with the fee calculation, make the calculator generic.

[sirnicolaz]

@kosecki123 what's the plan with this FlatFeeCalculator? Are we gonna use it only for the REDD pool? Otherwise, if the plan is to use it as a general fee calculator, maybe it would be better that the caller passes the scale to the _calculateFee function. In case we have another pool, then we don't need to deploy a new flat fee calculator.
alternatively we can keep it like this and redeploy a more general version later in case we have the need.

Depends on how you want to treat the fee calculators, as a shared deployed contract or per pool deployment. Either way we need to have the scaler.

I like the idea of passing the scale with the fee calculation, make the calculator generic.

Thinking about it, this issue can only happen with ERC20 tokens. ERC1155 tokens all have the same decimals, which is 0 (as they are non fungible and not fractionary)

[0xmichalis]

We don't need this feature after all since currently the pool contract takes care of the conversion. I have opened #57 to default feeToUnderlyingDecimalsScale to 1 but it may be best to just revert this PR, see #57 (comment)

[aspiers]

ERC1155 tokens all have the same decimals, which is 0 (as they are non fungible and not fractionary)

@sirnicolaz I don't follow this comment. ERC1155 is fully capable of supporting fungible fractional amounts. The standard even mentions decimals in the metadata URI JSON Schema. The only thing the standard is lacking is a decimals() getter on-chain (which strikes me as very odd).