Refactor: Unify DomainAddress and account conversions

[lemunozm]

Description

• Removed account conversions though Convert traits. Not DomainAddress know about to convert accounts.

• Unify DomainAddress to [u8;32]. See this slack thread

  • Before this PR you can transform a DomainAddress into [u8;32] in two ways:
    • Using T::DomainAddressIntoAccount::convert() which put 20 bytes from Eth + chain + "EVM" number.
    • Using DomainAddress.address() which put 20 bytes following by 0s.

  This is pretty confusing because is easy to use one or the other in different places, ending with different arrays values. From this PR, the second option is removed. We always add the extra information each time we extract the array from a DomainAddress

  • We need to ensure this is not a problem with out current chain state. From Solidity it seems not because Solidity always reads the first 20 bytes.
• Added sugar method to DomainAddress to easy work with them safely
• Renamed Centrifuge to Local (or maybe I revert this)
• Renamed EVM to Evm
• (only in IT). Removed From/Into traits from Keyring to H160 and [u8;20] and use instead an explicit method called in_eth() (open to name proposals). This method represents the account in the Ethereum network. Note that this differs from Keyring::Alice.into()[0..20], which is used in other places where an ethereum account is stored as an AccountId and needs to be recovered. Because this is highly confusing, I've removed the into/from methods to be more explicit about when the first case happens.

[lemunozm]

Current implementation is done as:

pub enum DomainAddress {
    Local([u8; 32]),        
    Evm(EVMChainId, [u8; 20]),
}

But I'm thinking of changing this into:

pub enum DomainAddress {
    Centrifuge(AccountId32),        
    Evm(EVMChainId, H160),
}

I do not like that we expose the AccountId32 type (which, theoretically, is set at runtime), but we would gain much more type safety. It's a pain to deal with arrays. Maybe it makes sense to expose an AccountId32 because speaking about a "Centrifuge domain" inherently carries some "domain information"

EDIT: after playing with the second approach, I feel like it's harder to deal with in a lot of scenarios, so I will keep the first model.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 60.34483% with 46 lines in your changes missing coverage. Please review.

Project coverage is 47.76%. Comparing base (e8f1efd) to head (764e4b2).

Files	Patch %	Lines
pallets/liquidity-pools/src/hooks.rs	0.00%	10 Missing :warning:
libs/types/src/domain_address.rs	76.66%	7 Missing :warning:
node/src/chain_spec.rs	0.00%	6 Missing :warning:
pallets/liquidity-pools-gateway/src/lib.rs	0.00%	6 Missing :warning:
pallets/liquidity-pools/src/lib.rs	85.18%	4 Missing :warning:
runtime/common/src/gateway.rs	0.00%	4 Missing :warning:
runtime/common/src/routing.rs	0.00%	3 Missing :warning:
runtime/common/src/account_conversion.rs	0.00%	2 Missing :warning:
pallets/axelar-router/src/lib.rs	66.66%	1 Missing :warning:
runtime/altair/src/lib.rs	0.00%	1 Missing :warning:
... and 2 more

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1967 +/- ## ======================================= Coverage 47.76% 47.76% ======================================= Files 183 183 Lines 12929 12887 -42 ======================================= - Hits 6176 6156 -20 + Misses 6753 6731 -22 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[lemunozm]

This PR wants to change 6e8f1a29dff0d7cf5ff74285cfffadae8a8b303f which is origin/main to 4301885b9a3b8ec36f3bda4b789daa5b115c006a

Good point! It was during the rebase...

[lemunozm]

Given the change from Local to Centrifuge, I should also change the as_local() and from_local(), I think both could be: as_account() (or just account()) and from_account().

Do you agree or do you have some preference? @wischli @cdamian

[wischli]

Given the change from Local to Centrifuge, I should also change the as_local() and from_local(), I think both could be: as_account() (or just account()) and from_account().

Do you agree or do you have some preference? @wischli @cdamian

Sounds good to me! {as, from}_centrifuge certainly sounds wrong. If we want to be more explicit, we could also use ..account32.. or ..account_id...

[lemunozm]

Well, I need to think a bit more because what's returned is the 32-bit array, so the account name may not make sense in some places where the array is expected (as when we construct a message with an eth address expanded to 32 bytes). Such a dilemma!

[lemunozm]

Closed in favor of: https://github.com/centrifuge/centrifuge-chain/pull/1969