Fix(eth-implicit-accounts): Do not assert wallet_contract_magic_bytes

[birchmd]

The eth-implicit accounts feature had been assuming that all Ethereum address-like accounts would be created implicitly (via a Transfer action as opposed to the CreateAccount action) and therefore always have the wallet contract "magic bytes" deployed. This invariant is maintained after account creation because the wallet contract does not allow adding full-access keys and therefore deploying different contract code is impossible.

However, on Near today there are already 5552 accounts (attached list: eth_addresses.txt) that will be classified as eth-implicit accounts. These accounts do have full access keys and therefore can have any arbitrary Wasm code deployed to them. Thus the supposed invariant of all eth-implicit accounts having the magic bytes deployed is in fact already broken.

This PR removes the assert from the runtime which was checking this invariant.

As a side note, the broader web3 wallets project will blacklist these 5552 accounts in the relayer implementation since the relayer also operations on the assumption that the accounts it interacts with will have the protocol-level wallet contract deployed and this assumption cannot be guaranteed on "legacy" eth-implicit accounts.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.66%. Comparing base (ea07739) to head (7fdffa7).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11606   +/-   ##
=======================================
  Coverage   71.66%   71.66%           
=======================================
  Files         788      788           
  Lines      161300   161300           
  Branches   161300   161300           
=======================================
+ Hits       115590   115592    +2     
+ Misses      40676    40675    -1     
+ Partials     5034     5033    -1     

Flag	Coverage Δ
backward-compatibility	0.23% <0.00%> (ø)
db-migration	0.23% <0.00%> (ø)
genesis-check	1.36% <0.00%> (ø)
integration-tests	37.86% <100.00%> (+0.07%)	⬆️
linux	69.06% <50.00%> (+<0.01%)	⬆️
linux-nightly	71.15% <100.00%> (+<0.01%)	⬆️
macos	51.04% <0.00%> (-1.58%)	⬇️
pytests	1.59% <0.00%> (ø)
sanity-checks	1.39% <0.00%> (ø)
unittests	66.24% <50.00%> (-0.01%)	⬇️
upgradability	0.28% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[staffik]

LGTM
I wonder if we assume this somewhere else
or someone can assume it in the future and what are consequences.
Maybe someone could exploit it by deploying custom contract to already existing ETH-like account. Is it possible to register such account in ETC?