Bridged usdc custom gateway

[gvladika]

Custom USDC gateway (for parent and child chain), complying with Bridged USDC Standard. These contracts can be used by new Orbit chains which want to provide USDC bridging solution and keep the possibility to upgrade to native USDC at some point later. This solution will NOT be used in existing Arbitrum chains.

Reference to the Circle's Bridged USDC: https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md

Expected flow of actions on a fresh Orbit chain could look like this:

• chain owner deploys upgradeable USDC token on parent chain, or uses canonical USDC if there is one
• chain owner deploys upgradeable USDC token on child chain, to be used ad bridged USDC, and inits the contract
• chain owner deploys upgradeable USDC custom gateway on parent and child chain
  • chain owner inits those gateways
• chain owner registers USDC gateway in router for USDC token
• chain owner assigns minter role to the child chain gateway along with max mint allowance
• now USDC can be bridged in both directions
• once transition to native USDC is agreed on, chain owner pauses deposits on parent chain
• chain owner then pauses withdrawals on child chain
• chain owner removes the minter role from the child chain gateway
  • there should be no in-flight deposits when minter role is revoked. If there are any, they should be executed (can be done by anyone by claiming the failed retryable ticket which does the USDC depositing).
  • if minter role is revoked before in-flight deposits are claimed, those funds can’t be minted. One option is to leave the gateway’s minter role, but decrease the allowance to match the total amount of unclaimed deposits
• chain owner sets Circle as burner on the parent chain gateway using setBurner(address) function
• chain owner reads the total supply of USDC on child chains. Then, he invokes setBurnAmount(uint256) on the parent child gateway where the amount matches the total supply
  • in case there are unclaimed deposits, their total amount should be added to the supply as those tokens shall eventually be minted by child chain gateway
• USDC masterMinter gives minter role with 0 allowance to parent chain gateway, so the burn can be executed
• on the child chain, gateway owner calls the setUsdcOwnershipTransferrer(address) to set the account (provided and controlled by Circle) which will be able to transfer the bridged USDC ownership and proxy admin
• if not already owned by gateway, bridged USDC owner transfers ownership to gateway, and proxy admin transfers admin rights to gateway
• Circle uses usdcOwnershipTransferrer account to trigger transferUSDCRoles(address) which will set caller as USDC proxy admin and will transfer USDC ownership to the provided address (according to standard [requirements](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md#token-roles))
• Circle calls burnLockedUSDC() on the L1 USDC gateway using burner account to burn the burnAmount of USDC
  • remaining USDC will be cleared off when remaining in-flight USDC withdrawals are executed, if any
• USDC token contract on the child chain is considered native now. Circle has ownership of the contract and can set minter, blacklister and other roles

PR containts USDC gateway implementation for parent chain and child chain, Foundry unit tests and Hardhat e2e test.

[gzeoneth]

lgtm, some comments
also new contracts can be added into storage test