System contract upgrade -- EOS balance row should not be removed even it is zero about eosio.contracts

[arhag]

There may be an argument for the system contract handler of new account to create a zero-balance table row in eosio.token for the core token symbol. To do this safely would require adding an open action to eosio.token to complement the existing close action, and have the system contract send an inline action to open that new table row.

The advantage of doing this is that it simplifies the initialization process to make an account a valid recipient of "safetransfers" of the core token, which I imagine nearly all accounts would want to receive since it is needed for staking and buying RAM. The disadvantage is that it increases the minimum amount of RAM necessary to create an account, including accounts that may never need to receive any of the core tokens at all (for example RAM may be gifted to them, stake delegated to them, and they just have no need to deal with the core token at all for some reason).

Either way, initializing zero-balances on account creation is not a solution for any other token other than the core token, because there is an unbounded number of potential tokens a user might be interested in receiving via "safetransfer" / "proxy transfer" for example.

Adding eosio.token::open (see #61) allows users to to pay for the RAM of the zero-balance table row for a particular token, so that future eosio.token::transfers of that token do not incur any additional RAM costs.

Changing eosio.token::transfer behavior (see #62) to never create a table row if one does not already exist (which necessitates the eosio.token::open action being available so that there exists a way to actually transfer a new token to a user for the first time) would mean that eosio.token::transfer would by default become safe from the perspective of the sender not incurring unexpected RAM costs. With that change, there would be no need for the "safetransfer" and proxy contract workarounds.

So the path forward seems to be to implement eosio.token::open (#61) as soon as possible and then some time later change the behavior of eosio.token::transfer (#62). With eosio.token::open implemented, there is also the possibly of updating the system contract to automatically open a zero-balance table row for the core token symbol when a new account is created.