Restrict receiving erc20 tokens

Description

When users bridge from Ethereum to Aurora Cloud (some specific silo), we need to verify that the recipient, are whitelisted in that specific Silo (if this whitelist mode is enabled). This is required to prevent non-whitelisted users from receiving tokens on the silo and breaking permission requirements, also having their tokens stuck. When a transfer happens and the recipient (and sender if feasible) don't satisfy our whitelisting requirements, that transfer is blocked, meaning that the recipient won't receive his tokens on the Silo.

It's also important that when the transfer is blocked, we instead transfer blocked tokens to our fallback address for tokens. This will help to make the manual recovery easier and won't add a significant security risk (as opposed to fallback just to the Silo/Aurora account itself and using admin access for the recovery).

Performance / NEAR gas cost considerations

There are insignificant gas cost increases. That is because we read from the storage the ERC20 fallback address in the execution of the ft_on_transfer -> receive_erc20_tokens method.

Testing

The integration tests that test the new logic have been added.

Additional information

Implementation:

Added new API set_silo_params to init/enable/disable the silo mode.
The set_fixed_gas_cost is left for backward compatibility, but it can't be used to enable/disable the silo mode anymore.
Verify if the recipient address is whitelisted on ft_on_transfer -> receive_erc20_tokens call, if it is not, then replace the passed recipient with the fallback_address

How should this be reviewed

The reviewer should focus on the changed components that are described in the implementation section, and verify that the implementation is backward compatible, and the integrity of the storage was preserved.

aurora-is-near / aurora-engine