Modify message verification inside ft_transfer_call for external receiver_id

[mrLSD]

Currently, we have NEP-141 compatibility restriction for nETH. The ft_transfer_call is not compatible with all kinds of message data because our implementation expects the following format of the message: <near_account_id>:<32 bytes fee><20 bytes for ETH address receiving the fee> . Having any other message provided or even an empty one (which is a popular option to use for exchanges) will result in a panic and transaction revert.

There's a reason why we were doing that: we are making that verification early in order to prevent future panics in ft_on_transfer (where it's hard to recover if there's an error). But as the message itself will be used only inside the ft_on_transfer , meaning that the message is intended to be processed by Aurora.

As @sept-en suggested we can do this early verification of the message format and overflow checks only if the receiver_id == aurora. Because otherwise, it makes no sense to force all other contracts to have the same message format as we do for Aurora.

[joshuajbouw]

Please add tests to ensure that it is working as intended.

[mrLSD]

When I added new test, I have got some strange case (it related to ft_resolve_transfer). I'm not sure is it correct:

    let balance = get_eth_on_near_balance(&master_account, "some-test-acc", CONTRACT_ACC);
    assert_eq!(balance, 2 * transfer_amount);

    let balance = get_eth_on_near_balance(&master_account, CONTRACT_ACC, CONTRACT_ACC);
    assert_eq!(balance, DEPOSITED_FEE - 2 * transfer_amount);

So looks like double-spent. I investigated it. It's from canonical implementation (from NEP-141) ft_resolve_transfer.

[joshuajbouw]

Well, if there are any double spends, this shouldn't be intentional at all, even if it is from a reference implementation. This warrants more investigation to ensure whats going on here.