feat: add fee handler for substrate

[viatrix]

Added a fee handler for Substrate.
Removed feeData.amount from txCost calculations.
Renamed fee handlers.

Description

1. Added a fee handler contract for Substrate based on FeeHandlerWithOracle (now renamed to DynamicFeeHandler).

2. Replaced feeData.amount with depositData.amount in txCost calculations. feeData.amount is not used at the moment but kept for possible uses in the future.

3. Renamed fee handlers:
   Created abstract contract DynamicFeeHandler
   Other fee handlers with oracle (dynamic fee handlers) inherit from DynamicFeeHandler:
   FeeHandlerGeneric -> DynamicGenericFeeHandlerEVM
FeeHandlerSubstrate -> DynamicERC20FeeHandlerSubstrate
FeeHandlerWithOracle -> DynamicERC20FeeHandlerEVM

Related Issue Or Context

Closes: #60, #122, #124

How Has This Been Tested? Testing details.

Added a unit test.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation

Checklist:

• I have commented my code, particularly in hard-to-understand areas.
• I have ensured that all acceptance criteria (or expected behavior) from issue are met
• I have updated the documentation locally and in chainbridge-docs.
• I have added tests to cover my changes.
• I have ensured that all the checks are passing and green, I've signed the CLA bot

[MakMuftic]

Hey @viatrix, my idea here was to also separate fee handler contracts for evm chains and generic message passing as separate implementations.

Currently, we have this logic inside FeeHandlerWithOracle:

if(oracleMessage.msgGasLimit > 0) {
    // txCost = dstGasPrice * oracleMessage.msgGasLimit * Base Effective Rate (rate between base currencies of source and dest)
    txCost = oracleMessage.dstGasPrice * oracleMessage.msgGasLimit * oracleMessage.ber / 1e18;
} else {
    // txCost = dstGasPrice * _gasUsed * Token Effective Rate (rate of dest base currency to token)
    txCost = oracleMessage.dstGasPrice * _gasUsed * oracleMessage.ter / 1e18;
}

that determines if the processed message (deposit request) is just a basic token transfer or a generic message (msgGasLimit > 0).

This approach allows users to do funky things like set this msgGasLimit when requesting fee data from fee oracle, but then execute erc20 token bridging with this fee data. I don't know how exactly this can be used for malicious behavior, but we should split this into two different implementations of FeeHandlerWithOracle. With this approach, we can map exact implementation based on resourceID and domains inside fee router and not even worry about how this can be used for malicious activity.

cc: @P1sar @nmlinaric @mpetrun5

[lastperson]

Suggested change

	txCost= oracleMessage.finalFee * oracleMessage.ter / 1e18;
	txCost = oracleMessage.finalFee * oracleMessage.ter / 1e18;

[lastperson]

Why formatting if it already has the same value?

[lastperson]

Formatting needs a bit of a fix.

[P1sar]

I think we also should update names. I think next should works better:
FeeHandlerGeneric -> DynamicGenericFeeHandlerEVM
FeeHandlerSubstrate -> DynamicERC20FeeHandlerSubstrate
FeeHandlerWithOracle -> DynamicERC20FeeHandlerEVM
or something like that. I am open for proposals