json schema to solve both auto re-constructor and abi problem?

[exalate-issue-sync]

At lowlevel, contract state, arguments to call contract and return value are all binary data (Uint8Array). For user's convenience, currently JS SDK decode it as utf-8 and parse it as JSON, results in a JS Object. We want to keep this behavior as this is 90% of the time what a user expects. In the other 10% case, the user could override the deserialize method to customize decode/parse behavior.

However, one thing not intuitive is objects are recovered as Object, not class instance. For example, Assume an instance of this class is stored in contract state:

Class Car {
    name: string;
    speed: number;
    
    run() {
      // ...
    }
}

When load it back, the SDK gives us something like:

{"name": "Audi", "speed": 200}

However this is a JS Object, not an instance of Car Class, and therefore you cannot call run method on it.
This also applies to when user passes a JSON argument to a contract method. If the contract is written in TypeScript, although it may look like:

add_a_car(car: Car) {
  car.run(); // doesn't work
  this.some_collection.set(car.name, car);
}

But car.run() doesn't work, because SDK only know how to deserialize it as a plain object, not a Car instance.
This problem is particularly painful when class is nested, for example collection class instance LookupMap containing Car class instance. Currently SDK mitigate this problem by requires user to manually reconstruct the JS object to an instance of the original class.

Please research on a feasible way of API design that can automatically reconstruct the instance instead of return a JS object. Some possible options could be:
- Using some type-awared format instead of standard JSON.stringify.
- Ideally still using a JSON based format to be human readable and intuitive.
- Or efficiently integrate some binary-based format such as cbor
- Store the type (schema) information separately with the data, either on chain or simply part of the contract code, and modify the SDK to auto make use of this part data to automatically recover instance.

Then propose a solution after research

• Demonstrate the overall benefit and downsides compare to alternative approach(es)
• Estimate time of effort you'll implement it
• this should be a full implementation to supersede existing SDK's reconstruct object mechanism and should be test against examples/src/nested-collections.ts

[ailisp]

Done in #370