Feat/vm1.5

[iulianpascalau]

Multi-async on a single level:
In a single-level multi-async we do not break the execution of scA when scA makes an asyncCall (in v1 we stopped the execution of scA, so asyncCall is always the last thing scA does in currently deployed and developed SCs), we only register the requests to the VM to make an async call after the execution ends. This registration saves the asyncCall info into a VM internal structure, plus a set of information persisted in the storage of the SC under protected keys (SC can read these keys, but cannot forcefully write under those, only by using the asyncCalls). Persisted information is cleaned up from SC trie after the asyncCalls and callBacks are concluded.
scA registers a number of asyncCalls and finishes its execution. The VM iterates on the registered asyncCalls and calls them in the order they were created. If one execution is intrashard, it will execute synchronously, in the case of cross-shard calls, those will be propagated as a smart contract result cross-shard, and a callback is called through a callback SCR. The function which should be called back is registered and persisted in the storage, so the VM will read from storage according to the unique IDs of the asyncCalls and get all the necessary information needed for the callback.
Introduced a limitation of multi-level asynchronous calls. AsyncCall from AsyncCall is not allowed. AsyncCall from callback is not allowed.

ManagedBigFloats:
Introduced a new API that targets bigFloats. Safe math with bigFloats, using standardized GO libraries.

ManagedMap:
Introduced a new API to support managed Maps for SC developers. Simple to use, all map features included.

BackTransfers:
We found that we can help developers, by changing some of the paradigms regarding SC to SC execution with payments. On the old VM if parentSC called childSC and childSC transferred back tokens to parents it must have called a “deposit” function and parentSC had to register that deposit into a storage. After that childSC execution is finished, we get back into the execution of parentSC and we have to read from storage what kind of transfers the child did towards itself.
Another problem with this is if parentSC is not payable by SC and childSC does not call deposit, only transfers, the execution will fail. This is even more complicated in asynchronous calls, and we found that if childSC is not well written, a malicious parentSC can make it problematic for the childSC. One example was the liquid staking contracts, where unbonded funds could get lost because malicious parentSC was not payable by SC.
So we decided to change the paradigm: When parentSC calls childSC and childSC does a set of transfers to the parent, the payable check is skipped for the parent. The check is skipped even if the parentSC called with asyncCall the childSC and even if childSC is in another shard vs. the parentSC.
Technically speaking: All transfers without execution from childSC to parentSC are accumulated in a new structure called backTransfers. In the end, the parentSC can do the following <payments, results> = ExecuteOnDest(child). This makes DeFi legoblocks easier to create.
The accumulated backTransfers can be read by the parentSC by calling the managedGetBackTransfers VM API.

Testing procedure

Pre-requisites

Based on the Contributing Guidelines the PR author and the reviewers must check the following requirements are met:

• was the PR targeted to the correct branch?
• if this is a larger feature that probably needs more than one PR, is there a feat branch created?
• if this is a feat branch merging, do all satellite projects have a proper tag inside go.mod?

[gabi-vuls]

System test passed.