More int types

[virgil-serbanuta]

Fixes #127

[ACassimiro]

Just for clarification, this modification now allows us to use unsupported types in our contracts, right? And the types will be handled by K as normal integers, without any special handling such as representing them using structs or tuples.

It seems clear to me, and I have no problems with it for our demos.

[yanliu18]

I did some research and confirmed that u256 is not a valid type in Rust, unless you are using some external libraries.
And the documentation in MultiverseX contract uses biguint and bigint to represent large numbers exceeding u64.
The rust builtin implementation of biguint can be referenced here.

Although, we might want to take shortcuts for Devcon demo, we should still maintain rust contract legal. What do you think?

The rest of the implementation looks fine for me.

[virgil-serbanuta]

Just for clarification, this modification now allows us to use unsupported types in our contracts, right? And the types will be handled by K as normal integers, without any special handling such as representing them using structs or tuples.

It seems clear to me, and I have no problems with it for our demos.

Yes. This is not a good solution in general, but it saves time for the demo.

[virgil-serbanuta]

I did some research and confirmed that u256 is not a valid type in Rust, unless you are using some external libraries. And the documentation in MultiverseX contract uses biguint and bigint to represent large numbers exceeding u64. The rust builtin implementation of biguint can be referenced here.

I know. There are two issues here:

1. ULM works with u256 while BigUint is either u800 or has unlimited size, depending on the context. I don't think we can just replace one with the other.
2. Implementing BigUint takes time (or have a similar implementation for u256). It's true that we would mostly be copy-pasting things from the original MX semantics, but even that takes time.

Although, we might want to take shortcuts for Devcon demo, we should still maintain rust contract legal. What do you think?

I mostly agree. My original plan was to implement a U256 type as a struct in Rust (for which we would have to fake implementations for operators somehow, and we would need to make encoding and decoding work for structs; we would also have a choice between making impl work for structs or using static functions for most things we need - all of these are easy-ish, but they take time, and we only have 3 days left until the deadline (or 4, depends on how you count)), or as a BigUint-like implementation where we keep the ints in a K map and we access them through hooks, and we would still need to wrap the int ID in a struct so we would still have the same issues as for the full Rust struct implementation.

However, I think that some of the leaders (Ilia or Xiaohong or both) said that adding the u256 type as a fake native type is an acceptable solution, so, while I dislike it, that's what I ended up doing.

The rest of the implementation looks fine for me.

[yanliu18]

@virgil-serbanuta I agree, we should work on more urgent task then. Thanks for the explanation.
Then I am OK to approve the changes.