Add support for language level errors (LangError)

[HCastano]

Implements the Message related changes of #1207.

The idea here is that every message now returns a Result<Message::Output, LangError>,
where a LangError is a type of error which doesn't originate from the contract itself,
nor from the underlying execution environment (so the Contracts pallet in this case).

An example of where this would arise is if a caller tries to use a non-existent message
selector for a contract. Previously, the contract would trap and not allow the caller to
do any sort of error handling if it encountered a non-existent selector.

This breaks the ABI in two ways: first, all contract messages now have a Result return
type, and second a new field, lang_err, will be introduced as part of the contract
spec. The second change allows other languages, such as Solang, to use an equivalent
LangError.

If you're curious, click here for a snippet of the new metadata for the Flipper contract.

"messages": [
  {
    "args": [],
    "docs": [
      " Flips the current value of the Flipper's boolean."
    ],
    "label": "flip",
    "mutates": true,
    "payable": false,
    "returnType": {
      "displayName": [
        "ink",
        "MessageResult"
      ],
      "type": 1
    },
    "selector": "0x633aa551"
  }],
"lang_error": {
  "displayName": [
    "ink",
    "LangError"
  ],
  "type": 3
},
{
  "id": 3,
  "type": {
    "def": {
      "variant": {
        "variants": [
          {
            "index": 1,
            "name": "CouldNotReadInput"
          }
        ]
      }
    },
    "path": [
      "ink_primitives",
      "LangError"
    ]
  }
}

TODO:

• Add new LangError type to metadata
• Add E2E test for demonstrating how to handle LangErrors
• Make CI green

TODOs in Follow-Ups:

• Implement changes for constructors (Handle LangError from instantiate #1512)
• Implement changes for traits (Fix trait message return type metadata #1531)
• Refactor dispatch logic to bubble up specific dispatch error
  • Will happen at the expense of always having an extra error variant in LangError
• Make the CallBuilder API not require an explicit Result (Clean up CallBuilder return() type #1525)

cc @xgreenx since you were the original poster for the issue

[ascjones]

This approach looks good, I think a unification of the LangError and DispathError is a good idea if you didn't already have that planned.

[xermicus]

@HCastano Can we use TypeSpec (together with an according builder method) in the contract spec instead, so it will work for Meta and Portable form? I was so free to push my proposed changes directly to your branch (also merged master and resolved the conflict), please have a look. If you are not comfortable with this just nuke my commits

Also CC @ascjones

[ascjones]

❤️ the comprehensive e2e tests

[ascjones]

Would testing err_flip_checked be useful do you think? As in it will be a Ok(Err(()))

[HCastano]

It could be useful, but maybe in the context of a different set of tests around error handling

[athei]

I think adding an error for NotPayable could be quite easy? Can be a follow up but calling return_value instead of using ? seems easy enough.

Apart from that it looks good to me. I compiled some simple contracts and the metadata looks sensible.

[HCastano]

I think adding an error for NotPayable could be quite easy? Can be a follow up but calling return_value instead of using ? seems easy enough.

Yeah now that this is in place it should be almost trivial to add that. Figured it would be better left for a follow-up though

[xgreenx]

I made a change to generate two sets of functions, the "original" unchecked function and the new "checked" functions (which are the ones with the Result<T, LangError> return types.

I think “unchecked” fits more for methods that return MessageResult, because we didn’t check the result it is why you can handle it=)

[athei]

Most idiomatic would be using try_ as a prefix. This is what the standard library will use to allow panic free allocation soon. For example: Vec::try_push.