Fix(ExitToNear): register the receiver account if it does not exist

[birchmd]

I cannot take my ETH from my Aurora address and exit to my NEAR account. I get the error Smart contract panicked: ERR_ACCOUNT_NOT_EXIST. This is because my account has never held ETH before, but I think I should still be able to send it there.

See https://explorer.testnet.near.org/transactions/91qBTPUe7iA7qzDzbivJgmkv3DEYJKdVTqL9JsRRyeH6 for full transaction log.

This PR removes the panic, and thus should fix the issue. I wanted to write a test to prove that (a) this was the problem and (b) this fixes it, but writing such a test turned out to be much much harder than the solution (this is a problem itself; tests should be easy to write because then we will actually write them!). So I decided to submit this fix first and the test later because I think the fix is very high priority.

[sept-en]

Really good catch!

Thanks for checking this!

As we want to somehow ask for a storage deposit for storing the information about the account, let's register the account explicitly during the ft_transfer process. So the FungibleToken's transfer function will look something like this:

    pub fn ft_transfer(&mut self, receiver_id: &str, amount: Balance, memo: &Option<String>) {
        sdk::assert_one_yocto();
        let predecessor_account_id = sdk::predecessor_account_id();
        let sender_id = str_from_slice(&predecessor_account_id);

        if self.accounts_get(&receiver_id).is_none() {
            self.accounts_insert(&receiver_id, 0);
        }
        self.internal_transfer_eth_on_near(sender_id, receiver_id, amount, memo);
    }

We can put this functionality into EthConnector's ft_transfer instead. It's up to you. But probably putting this into FungibleToken will make the testing easier.

[birchmd]

let's register the account explicitly during the ft_transfer process

Done in be4c7bf

[sept-en]

Also, I noticed that the check if the account contains a key is a little bit redundant, as the same thing is being performed in accounts_insert() method. But it makes sense to keep it as most likely we will add some logic for storage depositing there.