feat: CairoTypeOption CairoTypeResult CairoTypeCustomEnum and others

[PhilippeR26]

Motivation and Resolution

In the frame of the new parsing strategy, implementation of Cairo option & Cairo result type.

Usage related changes

No user change.

Development related changes

Current CairoOption, CairoResult & CairoCustomEnum classes remains unchanged, and is used by users.
New CairoTypeOption, CairoTypeResult & CairoTypeCustomEnum classes are created in conformity with the CairoType interface, and are used to encode/decode to Starknet API. Can be used by user, or is automatically created from a CairoOption.

       USER                             Starknet.js                   USER
    CairoOption    
 CairoTypeOption -->         CairoTypeOption --> encode/decode --> CairoOption
 
    CairoResult    
 CairoTypeResult -->         CairoTypeResult --> encode/decode --> CairoResult

 CairoCustomEnum
CairoTypeCustomEnum -->  CairoTypeCustomEnum --> encode/decode --> CairoCustomEnum

Added also CairoNonZero, CairoEth, CairoEthAddress, CairoBool classes, CairoStruct.
Also handling of ContractAddress & ClassHash (are in fact just felt252).

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[PhilippeR26]

Added a commit to solve problems of recursive decompose.

[PhilippeR26]

Added a commit to solve several problems of recursive encoding.
Remains to handle named tuples.

[PhilippeR26]

@tabaktoni
Now we have full recursive encoding and decoding for tuple, array, fixed array, option.
Cairo0 handling: felt, named tuple ( {a:10, b:20} ) and array (felt*).

• felt has been added in strategy for Cairo 0 handling (is just using felt252 class).
• tuple decoding is an object (named if is a Cairo 0 named tuple).
• as named tuple do not exists in Cairo1, existing code of CairoTuple.extractTupleMemberTypes() has to be reconsidered.
• Tests not yet updated.

[PhilippeR26]

@tabaktoni
It's now working with all Cairo v2 I tested (and I tested a LOT of things).
I have no infra to test Cairo v0.6 & v1.
So, I think that job is done in CairoDataTypes folder.
I am now digging in calldata directory ; seems there are several possible optimizations using this new concept.

[PhilippeR26]

Ready for review.
Test suite is passed successfully in Devnet, but there is no Cairo0 or Cairo v1.x tests (as Devnet is no more handling these versions).
In addition, additional tests have been performed (can be found in https://github.com/PhilippeR26/starknet.js-workshop-typescript/tree/main/src/scripts/Starknet140/Starknet140-devnet , 6 to 15).

[penovicp]

Suggested change

	return addHexPrefix(this.toBigInt().toString(10));
	return this.toBigInt().toString(10);

[penovicp]

What is the reason for the hex to decimal swap?

[PhilippeR26]

Because test suite is expecting everywhere decimalString for a Calldata.

[penovicp]

Would it make sense to stop supporting u96?

[PhilippeR26]

Cairo language u96 is still supported, but in abi it's not named 'core::integer::u96' ; it's named 'core::internal::bounded_int::BoundedInt::<0, 79228162514264337593543950335>'

[PhilippeR26]

I performed local tests of encoding/decoding of Cairo 0 & cairo V1.1 contracts.
It works, but I found problems for decoding of Cairo 0 arrays and Uint256.
Last commit is solving these problems.
So, should be now OK for all versions of Cairo.